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(57) Abstract 

An automated communications system operates to transfer data, metadata, and methods from a provider computer (1) to a consumer 
computer (2) through a communications network (3). The transferred information controls the communicUons relationship, including 
responses by the consumer computer (2), updating of information, and process for future communications. Infonnation which changes 
m the provider computer (1) is automatically updated in the consumer computer (2) through the communications system (3) in oixlcr to 
mamtain continuity of the relationship. Transfer of metadata and methods permits intelligent processmg of information by the consumer 
computer (2) and combined control by the provider and consumer of the types and content of inforaiation subsequently transferred. 
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AN AUTO MATH) COMMUNICATOKS SYSTEM AND MEIHOD FOR TRANSFERRING INPQR. 
MAHONS BETWEEN DATABASES W ORDER TO CX)N1K0L AND PROCESS GOMMUNICa. 
TIONS 

1. Field of the Inventinn 

The present invention relates to data communications systems. More particularly, it 
5 relates to an automated communications system which coordinates4he transfer of data, metadata, 
and instructions between databases in order to control and process communications. 

2. Discussion of the Related Art 

All communications consist of a mechanism for exchanging information between one 
10 entity, a provider, and another, a consumer. The terms "provider'' and "consumer" are used to 
designate separate functions in mformation transfers. Typically an entity, at various times, 
operates as both a provider and a consumer in any communication relationship. These 
relationships may be one-to-one, such as between two individuals; one-to-many, such as between 
company and its customers; or many-to-many, such as between the members of a workgroup. 
15 These communications relationships may also exist over multiple communications networks, 
such phone networks, LANs, public data communications networks, radio and TV networics, 
wireless networks, and conventional postal mail networks! 

Establishing, maintaining, operating, and even terminating any one of these types of 
communications relationships involves significant woik on the part of both the provider and 

20 consumer . For example, to initiate any type of communications relationship, providers must first 
locate the consumers with, whom to communicate and vice versa. Solving this problem is subject 
of several entire industries, such as the directory industry, the mailing list. industrv\ ahd the 
advertising industiy. Once a provider or consumer has been identified, contact information (e.g., 
names, titles, addresses, telephone numbers, electronic mail addresses, etc.) must be exchanged 

25 between the provider and consumer. This contact information must be maintained by both 
parties so that fiiture communications can be effected as needed. When the contact information 
changes for an entity, all providers or consumers having relationships with the eniit\^ must be 
notified of the changes, who in turn must update their own records. This work also extends to 
other data and records exchanged in the context ofthe communications relationship, e.g. orders, 

30 receipts, product numbers, invoice numbers, customer numbers, notes, brochures, reports, etc. 
Maintenance of this information requires significant human time involvement for receiving 
information, storing information, indexing information, searching for desired information, and 
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retrieving, iafonhatipn. The human compondtt of record maintenance also creates a potential for 
error, which can cause the information to be feulty or to become lost 

Once the communications relationship is established, the next major worlcload is the 
active use of the relationship to accomplish communications objectives. The problems here take 
5 dififereht forms depending on the type of coinmunicadons relatiohsWp; F6f wimple, in a one-to^ 
many relationship, particularly a mass-market relationship such as a company and its customers, 
the problem is how to efficiently disseminate information about products and services to 
consumers. Optimally, such information would be disseminated only to the consumers who need ^ 
the information^ only at the precise time they need it, and only via the communications network 

10 the consumer preferred. However, knowing who neieds what information, when, and how can be 
veiy difiFicult Therefore, providers typically disseminate information widely in the form of mass 
advertisements and mailings via all possible communications mediums in order to reach all 
likely consumers. Because of this broad dissemination by providers, consumers recei ve large 
amoimts of information, much of v/knch is inelevant to them. Consumers are forced to sort and 

15 filter through this information, and frequently much of it is discarded. Information which is kept 
may not be immediately useful, but may: be needed at a consumer expends • 

a great deal-of work to store, catalog; and index this information; the information can be difficult 
or impossible.to.fmd when the consumer actually, needs in 

This.same problem of efficient information in many*to-many . ' 

20 conmiunications relationships, such as among the members of a woikgroup. Here, 

commtmications are much more frequent and timely, and there is much greater quantity of 
information to be shared, stored, archived, and indexed. Menibers of a workgroup also have a 
strong need to employ communications for groiip coordination, such as scheduling meetings, 
conference calls, project deadlines, etc. These cornmuxiicatiohs involve time deadlines and 

25 feedback requirements which are not typically present in one-to-many communications 
relationships. 

With one-to-one communications relationships, the problem of efficient information 
disemination is lessened because the parties typically have a much higher knowledge of each 
other's needs and interests. Conversely, the need to use communications for coordination 
30 purposes is greatly increased, largely because between individuals the need for real-time 

communications sessions such as phone calls and personal meetings is acute. Thus the universal 
problem of "phone-tag", when both parties exchange ntinierous mess^es trying to coordinate the 
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opportunity to communicate in real time. 

The next workload involved ia communications relationships is when the parties need to 
exchange, process, and store structured data. In a one-to-many communications relationship, a 
common example is a consumer ordering a product The consumer must place a telephorie. call, 
5 locate a salesperson, and then manually transmit the necessary pidprmg infonhatioii, which the 
, salesperson must manually record. Paper or electronic product order forms can help automate 
this process for the provider, but they still must be filled out manually by the consumer. Many of 
these forms require the same standard inforaiation from the consumer, which the consumer must 
enter repeatedly. All of these infonnation transfers require huoan involvement and thus create 
10 the potential for data eirors. On the provider's part, more work is required to pcrfonn error 
checking on the order, process it, and in many cases return an acknowledgment to flie consumer. 
,^ Many providers invest heavily in data processing and electronic communications systems for 
automating these functions. However, the lack of a standard communications system for 
exchanging common data means diat providers adopt largely proprietary systems, increasing the 
15 investment necessary for every provider. In addition, consumers must stUI interact with each 
these systems manually. 

In a many-to-many conamunications relationship, such as a workgroup, the need for 
structured data exchange is even higher, especially when automated data processing tools such as 
computer software are in widespread use. Also, the need for strucnired data exchange for 

20 workgroup coordination activities, such as scheduling and planning, grows significantly. 

One-to-one communications relationships may also involve strong needs for structured 
data exchange. For example, two individuals from different companies may need to review and 
revise a document involving both companies. The ability to do so electronically, using a secure 
method of exchange over public data networks, would make the task considerably easier. 

25 Individuals involved with one-to-one communications relationships also have an acute need to 
use structured data exchange to solve the problem of scheduling communications sessions, i.e. 
the phone-tag problon. 

Since all communications relationships are inherently dynamic, they involve three other 
common tasks involved for providers and consumers: copying the relationship, transfering the 
30 relationship, and terminating the relationship. Copying.is when one consumer wants to share a 
particular communications relationship with another consumer. For example, a mail-order 
catalog customer may wish to give a copy of the catalog to a friend, or a businessperson may 



BNSCX3CIO: <W0 0732251A1.I > 



wo 97/32251 PCT/US97/032a5 . 

-4- 

necd to share the phone number of a colleague with a customs. Tiansferrmg is when one 
provider assumes a consumer communications relationship from another, or one consumer 
assumes a provider communications relationship from another. An example would when a 
company changes the salesperson responsible for the customers in a sales territory, or when a . 
5 customer transfers ownership of a product Tenmnatipn.is.wheh either a provider or consumer 
. voshes to end a communications relationship, i.e. a provider no longer wants to distributes . 
infonnation, and/or a consumer no longer wants to receive, process, or store the infomiatioh. A 
widespread example is consumers who wish to be dropped from direct mailing lists, and the 
providers who wish they could efficiently identify such consumers to save mailing costs. All 

10 three of these common^ everyday commtmications relationship operations involve considerable 
effort on the part of the provider and consumers to carry out. 

Therefore, a need exists for a communications system which allows providers arid 
consumers to quickly and easily establish an automated communications relationship, one in 
which the data necessary to operate the communications relationship is exchanged and updated 

15 automatically, and which can control all types of commimications via all tyj^ of 

. conmiunications.network common to both the provider:and'Consiimer; A need also exists fora' 
communications system:which:allows aiprovider to actively notify a consuiner of new : 
information in which the consumer may. be interested, and which allows the consumer to 
precisely filter: the information being sent by one:or more providers. A need also exists for av 

20 conmiiuiications system which allows providers and consumers to automatically structure, 
exchange, and process incoming or outgoing communications to the greatest extent possible. A 
need also exists for a conununications system which allows providers and consumers to easily 
share access to many common communications services. Finally, a need exists for a 
conununications control system which allows providers and consumers to easily copy, transfer, 

25 and terminate communications relationships. 

. Various computer-based systems have been created to provide mechanisms for 
conununicating information. The Internet and World Wide Web provide a network of a large 
number of infonnation sources, providing a voluminous amount of infonnation. Computer 
programs exist which can be executed on Internet-connected computers to search these sources to 

30 obtain desired information. Additionally, through tiie medium of hypertext, providers of World 
Wide Web.pages can create links in their pages between items of related information which can 
significantiy aid consumers in finding desired information. However, the hnks to the 
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infonnation source ate neidier dynamic nor persistent; in the sense that tiiey do not provide new 
or updated infonnation once the consumer has found a topic of interest. "Bookmarics^' in a web 
browser program can ftcilitate subsequmt access to a particular web page to determine if new 
infonnation is present However, if the web page referenced by the bookmark is removed, the 
5 bookmark is no longer valid. Bookmark poUingprograms, such as Smart Bookmarks from First 
■;■ Floor, Inc., can also be used to determine whetho- a web page has changed since the last time the 
consumer viewed it In addition. Smart Bookmarics can examine a changed page and 
automatically transfer to the consumer a text string embedded by the author of the page 
infonning the consumer of the nature of the change. However, Smart Bookmarks' capability is 
10 Umited to single text strings on single web pages. Therefore the consumer must locate and 

bookmark every Web page of interest. Smart Bookmarks does not provide a way for the 
-f consumer to filter the update messages, nor does it provide the consumer with any mechanism 
for exchanging structured information or managing a communications relationship with the 
provider. 

15 A different type of Web monitoring solution is provided by Revnet Systems Inc. With its 

GroupMaster software, Web providers can create and insert special hyperlinks representing 
interest topics on the pages of their Web site. When a consumer clicks on this link a special data 
file is transferred to the consumer's GroupMaster client software. The client software then polls 
the Web server for updates to the interest topic input by the provider. Unlike Smart Bookmarks, 
20 all interest topics at the site can be checked in one update poUing action. Update messages can be 
delivered to the consumer via the client software. However, these messages only contain links 
back to pages with follow-up infonnation at the Web site. They do not store or index infonnation 
fiom the provider, nor do they provide a mechanism for the consumer and provider to automate 
. . other types of stmcnired data exchanges or manage a communications relationship. 
25 Online navigation or "auto pilot" software, available ftom various commereial online 

.;. services or software companies, can help the user automate access to online services, the Internet, 
and other public networks. The software provided by these services or companies can include 
capabilities such as automatic logons, automatic navigation of the online system according to 
=s consumer preferences, file searches, uploading and downloading data, and storage of data. Some 
30 . systems can also automatically download the date necessary to update their own operation. 
. However, the navigation software available from the online services typically requires that the 
consumer first establish an account with the online service, and may also involve establishing 
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accounts with specific providers on the service: in addition* these navigator programs are 
specifically designed to work withihe architecture and corhmunications protocols of the online 
service, and cannot be easily adapted to other data communications networks, thus preventing 
other providers from using the functionality of tiie online service to create and distribute data in 
5 the same manner. Finally^ they require that the consumer set up and ihaihtain a cbinmumcations ' 
relationship with each informatibh provider on die service. * If the provider changes its ' 
information offerings, the consumer must reprogram the autopilot or navigation software. This 
last disadvantage also applies to online navigatidii programs designed to woric with the Internet 
and other non-proprietaiy public data nenvorks. 

10 Electronic mail (e-mail) systems are another electronic communications system that 

provides some conununications contact persistence. E-mail addresses and messages can be 
stored and indexed within e-mail programs, or externally in other locations. E-mail rules engines 
allow for some degree of automated storage or response to certain message contents. However, 
these rules engines are typically constrained to acting on certain known information about the 

15 messages, such as the address ofthe message provider, or on seniahtic rules such as keywords 
which;mustbe:gue5sed.'by:the provtder^and 'consumer:t;T^ . 
frame of referenceri.e., a structured data format and operations methodology; against which both 
the provider and consiunercan operate. to filter; ciassify.vand organize messages.: The lack of a 
conimon frame'X>f reference-also severely'U'mits tbe capabUity.of either t^^ provider or consumer 

20 to automatically process the contents of an e-mail message, or to automatically respond to the 
message besides the capability to automatically address a reply message. 

E-mail systems which support electronic forms overcome some of these limitations. 
Electronic forms allow the provider to control the content of a forms submission and to 
automatically or semi-automatically route that data around a network. Electronic forms also 

25 allow message consumers to automate a response to the forms provider which can be 

automatically processed by the provider. However, these fomis must be received and processed 
by the consumer in the same manner as conventional e-mail messages. In other words, they do 
not provide a means for the consumer to control or filter messages from different providers. 
Forms also do not provide the consumer with a mechanism for automatically storing, indexing, 

30 or processing information from the provider. In addition, while they may automate the provider's 
ability to process the data returned from the formsv the consumer must still manually enter 
information in the form. 
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SpeciaUzed e-inail systems have been developed that combine the use of electronic fonns 
with a system-wide data processing model. Examples are The Coordinator from Action 
Technologies, Inc., or OVAL from the MIT Center for Coordinatiofl Science. These systems 
allow providers and consume to share a frame of reference for messaging such that messages 

5 can be classified mto specific cate|Qrie$ and actions. This aHows j^^ 

consumers to automate the routing, storage, and processing of messages based on these categor>' 

. and actions. However, these systems require that aU providers and consumers Share the same 
frame of reference. They do not provide a generalized means for each provider on the system to 
establish and update their own frames of reference with one or more consumers, nor a 

10 generalized means for each consumer to coordinate the frames of reference they have with 
different providers. 

A different approach to the problem of automating communications is the category of 
software that is commonly referred to as "software agents" or "mobile agents". An example is a 
platform for communications applications developed by General Magic, Inc. called Telescript 
15 The Telescript language is an objectK)riented, remote programming language witii three core 
concepts: agents, places and "go". Agents "go" to places, where they interact vrith other agents 
to get work done on a user's behalf. Agents are mobile programs capable of transporting 
themselves from place to place in a Telescript network. The language is implemented by the 
Telescript engine. The Telescript engine is a multitasking interpreter that integrates onto an 
20 operating system through a programming interface called the Telescript API. The Telescript 
engine operates on server computers connected over a communications network. Telescript 
agents can operate independently anywhere within these server computera to control the transfer 
of message data and perform programmable actions upon that message data. For example, if a 
message recipiem is not available, the message could be rerouted to a different- location, rather 
25 . than being returned to the sender undelivered. Telescript is similar to other agent technologies in 
that the architecture is based on agents interacting with other agents on server computers rumiing 
agent "engines" or mteipreters. In this architecture, the establishment of a communications 
relationship requires two agents: one to represent the provider and one the consumer. Although 
agent programming systems like Telescript provide the necessary tools for creating these agents. 
30 , it is still necessary for both the provider and consumer to create and^administer the necessary 
agents, Furthermore. Telescript does not provide a specific model for the filtering, storage, and 
indexing of communications between a provider and consumer via agents.- Lastly, agent 
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architectures require the addition of servers running agent intopreters to the conununications 
network in order to operate, increasing the expense and complexity of the network. 

A more specialized type of agent technology is delivery agents. Examples include Digital 
Delivery from Digital Delivery, Inc. and PointCast from PointCast Inc. Delivery agents do not ' 
5 require a network of specialized servers; but instead operatis directly on a consiimer^s computer to 
retrdve information of specific relevance to the user over a network. They are created by a 
particular provider to supply iriformation from a server or servers under that providers control, or 
from a more generalized news source such as a wire service. Delivery agents allow a consumer to 
specify his/her topics of interest, uiiich the delivery agent then uses to filter the available news 

10 stream and show the user only the information of interest Delivery agents are also capable of 
storing and indexing the received data for the consumer Other than communicating the 
consumer's topic preferences back to the provider, however, delivery agecits do not provide a way 
to control or process other communications between the consumer and provider. In addition, 
since each delivery agent is typically designed as a separate executable program which must be 

15 installed and run separately, the consumer is limited as to the number of delivery agents the 
consumer can manage and run. . 

Another approach to autpniating'conunutiicatioris and data trari^^ is shared replicated 
database systems such.as Lotus.Notes and.CollabratShare; With these systems, information to be 
. coimnunicatedi is entered via-^a client program into one dr more databases' which may reside 

20 locally on client computers or on network server computers. These databases are then replicated 
to other server computers or local client computers throughout the system so that the data can be 
easily accessed by any other user of the system v/ho needs the information and has the proper 
access privileges. Access privileges are controlled by one or more system administrators via the 
system servers. Some of these systems, notably CoUabra Share, also allow users to "subscribe" 

25 to specific databases. These users can receive an e-mail notification from a database agent 

monitoring the database when a new entry or a certain condition has been made in that database. 
These systems may also employ electronic forms and forms processing languages to structure the 
data being entered into a database, and to take programmable actions based on the data entered. 
The architecture of these systems is designed for groups of users to share information related to 

30 specific topics, and to automate the transfer of data- between different computer applications used 
by an organization. For this reason the core data stmcture of the architecture is a subject 
database or "forum". Each subject database covers a number ofrelated interest topics under 
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which all entries in the database are categorized.. All copies of any subject database are 
synchronized throughout the system when data in any one copy has been changed. 

While suitable for information sharing amongst the members of a group, this architecture 
is not well suited for automating conununications relationships among a large number of 
S infonnation providers and consumers. First;; all the providers and cons^ 
: interconnected through the system in order to communicate. This could be done by having all 
. providers and consumers enroll in one large system in which they all had access privileges. In 
such a system each provider would need to have at least one subject database for communicating 
with his/her consumers. This enormous number of subject databases would then need to be 
10 V replicated among the large number of servers required to service the complete population of the 
system, which would quickly overwhelm the capacity of the servers or network to handle 
'% replication. A more realistic alternative would be to have each provider or group of providers 
operate and administer their own system, making their internal subject databases available to 
consumers via public data networks such as the Internet. Consxuners would use the system client 
15 software to "subscribe" to the subject databases of each provider with which they desire to 
communicate. Only the subject databases a consumer subscribed to would be replicated on 
his/her desktop. This solution would spread the replication load to a lai^e number of servers, 
each handling a smaller amount of traffic. However, each server would now have to manage 
replication for a large number of external consumers as well as internal group members. There is 
20 noeasy way to distribute this replication load to the consumer's computer. Second, subject 
databases do not allow the consumer to control and filter the incoming conununications from 
providers. Consumers must still scan the databases for items of interest. Providers could 
overcome this by creating a subject database for each interest topic, but the additional 
administrative and server replication overhead would strongly discourage this. Third, because 
25 notification of new information is handled via a separate application, e-mail, the consumer is 
* forced to coordinate notification and dak storage/response among two communications systems. 
Fourth, since subject databases are replicated from the servers, they do not give consumers an 
easy way to copy or transfer them to other consumers. Finally, because the entire system depends 
on server-based replication, administrative changes or reconfigurations of these servers such as 
30 system name or address changes require administrative updates tq.all subscribing consumers, a 
job which consumers must handle manually. 

Consequently, a need exists for a communications control system which allows providers 
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and consumers to quickly and easily establish an airtomated w relationship; which 

automatically updates both parties with chariges in communications control data from the other; 
which works with all communications networks shared by the provider and consumer; which 
aUows both parties to automatically control, filter, store, index, and process communications 
froni the other; >^ch allows both providers and consum - ' . 

communications services; and which allows both parties to easily manage, copy, transfer, and 
terminate the conlmunications relationship. 

SlJMMARYOF THHTNVFMTTnKI 
The disadvantages of existing communications control systems are significantly 
overcome by the present invention m which software programs being executed by a provider 
computer and consumer computer communicate directly in order to maintain a communications 
control structure: this smicture originates at the provider computer and is transferred to the 
consumer computer.- Changes to the structure on the provider computer rcsuh in an updated 
15 version being transferred to the consumer computer. The communications control stmcture 
contains;.a combination'of data;:metadata,^and:iiistru^ the respective : 

programs to control the origination: of outgomg communications ahd tht processing of incoming 
commiuiicationsvbetween the provider and consumer.'-' ^ 

In one aspect of the present invention, a communications system is used to coordinate 
20 communications between providers and consumers. Provider computers transfer information 
stored in the provider computer through a communications network to a consumer computer. 
The information includes processes for updating the transferred information in the consumer 
computer when the information in provider computer has changed. For "push" processes, the 
provider computer maintains address data necessary to transfer updated information to various 
25 consumers. For "pulf processes, the consumer computer uses information transferred from the 
provider to access a location where the provider information is stored to determine whether it has 
been updated and to retrieve it if necessary. 

According to another aspect of the present invention, existing conunuhications networks 
and network accessing programs are used to increase the functionality of the conuniinicalions 
30 system. The Internet and World Wide Web, or similar type networks, arc used to access and 
transfer the information. According to this aspect, infonnation is created and maintained 
according to a recognized protocol; such as HTTP, MIME and HTML; which can be used to 
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access other information. An iq:pToiffiate di^lay program, such as a web browser, is iis^ to 
retrieve and display die infbrniation. 

According to another a^t of the.present invention, programs operating on the Jwovider 
computer and consumer computer opoate as state machines m connection with an appropriate 
display program. The programs operate to receive information requests from a display program 
and to generate a next di^lay containing the requested information. 

According to another aspect of the present invention, information is d^aiiized in a form 
which simpUfies transfCT of data, metadata, and instructions. Object oriented programming is 
used for combining data, metadata, and methods for storage and transfer. Specialized object 
classes and type definitions are used to provide imelligence in processing of transferred 
infoimation. Elements m an transferied object can be used by the consumer computer to filter 
^ information and provide selective notification to a user of changed information. The 
combination of methods and data permits joint control by the provider and consumer over the 
information transferred, together with how updates, responses, and acknowledgments are 
15 processed. 

According to another aspect of the invention, a provider program is used to create, edit, 
and maintain data, metadata and instructions in a provider database. The provider program also 
controls distribution of the information to various consumeis. Different information contained in 
the provider database can be transferred and used in communications relationships with different 
20 consumers. The provider database includes information associatmg the information with each 
potential recipient. The association information is used to selectively distribute information and 
information updates. The provider program also receives and uses information from the 
consumer computer to control encoding and transfer of information to the consumer computer. 
According to another aspect, the provider program uses a mariciq) language to format the 
25 information for transfer. 

According to another aspect of the invention, a consumer program is used to receive and 
process the transferred information. The consumer program receives information from the 
provider or polls a location identified by the transferred information to determine when 
information has been updated by the provider. The consumer program then retrieves the 
30 information from the proper source and compares it to the existing.information to determine 
what has been updated. The consumer program maintains a database of information from 
differem providers. When updated information is.received, the consumer program executes 
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instructions associated ^.th the infpnnation to store the updated information, notify a user of 
iqjdated information, and generate responses for the consitiner. The coiisumer program also can 
transfer the information to second consumer computer. The second consumer computer can 
obtain updated information fix>m the provider con^iuter or have it forwarded by the first 
5 consumer computer. 

According to another aspect of the invention, methods in the commuilcatiohs objects are 
used to automate control of underlying communication operations. When obtain actions are 
taken by a user, or when certain types of messages or objects are received, the respective 
consumer and provider programs can operate automatically based upon selected methods and 

10 operations in order to act with or without input from the users. For example, acknowledgements 
can be automatically formatted and sent Also, objects can be automatically transferred to others: 
The consumer program can transfer the information to a second consumer computer, with or 
without notification or approval of the user of the consumer program. The second consumer 
computer can then obtain updated information from the provider computer or have it forwarded 

15 by the first consumer computer. Exchange of significant data, metadata, and methods, and 
archiving or retneval of changed;objects can<be.autoniaticall^^ by the programs. 

Methods can also be.used to coordinate-suspension or terminatiomof communications 
relajtipnships... 

According' tc another aspect of the invention,' service objects and^ partner servers are used 
20 to provide data, metadata, and instructions which can be used by providers and consumers to 
. automate various conununications services desired by both. The data, metadata, and instructions 
are received by the provider and consumer computers in the same manner as information is 
received by the consumer computer. The provider can include data, inetaidata, and instructiotis in 
the service object in the information transferred to the consumer computer. The information 
25 transferred from the service partners also controls communications with the service partner for 
both proNdders and consumers. Both providers and consumers can use service objects to 
conununicate with a partner server in order to obtain communication services provided by the 
partner server. 

. According to another aspect of the invention, the provider and consumer programs and 
30 databases are combined to obtain additional ^functionality. ^The communication system can allow 
multiple users for a single piogram and database. The data, metadata, and inistructions 
coordinate the operation of the programs for each user and allow for conununications between 
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users of the single database. 

With these and other objects, advantages and features of the invention that may become 
apparent, the nature of the invention may be more clearly understood by reference to the 
following detailed c^pription, the appended claims, and the several drawings attached hereto. 

5 

BRIEF DHSCRTPTION OF THF PR A WTMHtg 

FIG, I illustrates a communications system according to an embodiment of the present 
invention. 

FIG. 2 illustrates an embodiment of the provider program and consumer program of FIG. 
10 1 as state machines. 

FIG. 3 illustrates object oriented data structures for storing communications data. 
FIG, 4 illustrates the lower branches of FIG. 3, and instances of various elements. 
FIG. 5 illustrates the use of a system ID server. 

FIGS. 6A and 6B illustrate object oriented data structures for storing system ID data 
15 within the system ID database and for user objects. 

FIG. 7 illustrates a pull method of transmission of a communications object 
FIG. 8 illustrates a push method of transmission of a communications object. 
FIG, 9 illustrates operation of a provider program of FIG. 1 according to an embodiment 
of the present invention. 

20 FIGS. IDA and lOB are block flow diagrams of operations of the processes for form ' 

submissions and update associations. 

FIG. 11 is a block flow diagram for a process for distributing a communications object 
FIG; 12 is a block flow diagram for a conrununications object generation and 
tran^ission routine. 

25 FIG. 13 illustrates operation of a consumer program of FIG. 1 according to an 

embodiment of the present invention. 

FIG. i 4 represents a user interface display for a fomi for inputting information in 
conjunction with an embodiment of a consumer program. 

^ FIG. 15 is a block flow diagram for a process for receiving a dommunications object 
FIG. 16A is a block flow diagram for the main eyent loop;of the consumer or provider 
program. 

FIG. 1 6B is a block flow diagram for the scheduled event loop of the consumer or 
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provider program. 

FIG. 1 7 Illustrates the object oriented database stnictures for different communications 
object types. 

FIG. 1 8 illustrates object oriented data structures used for distribution control. 
5 FIG. 1 9 is a block flow diagram for a process for generating an object when page " 

distribution control is used. 

FIG. 20 illustrates operation of the coramlmicadbns system for distribuuon control using 
a pull method of transmission. 

FIG. 21 illustrates operation of the communications system for encoding control, 
10 FIG. 22 illustrates a user interface display of a form for creating notification elements in 

the provider program. 

FIG. 23 illustrates a user inter£Bu:e di^lay of notification elements on a edit object form 
in the consumer program. 

FIG. 24 illustrates a user interface display of a notification report. 
IS FIG. 25 illustrates operation of the communications system for data exchange involving 

technical support of a software product * 

FIG. 26 illustrates a user interface display of technical support options for users of a 
software product 

FIG. 27 illustrates a user interface display of an input fomi for gathering technical 
20 support information. 

FIG. 28 illustrates operation of the communications system for service objects. 
FIGS. 29 A and 29B illustrate object oriented data structures for a directory system and a 
message or discussion thread. 

FIG. 30 is a block flow diagram for a process for creating directory listings using service 
25 objects and partner servers. 

FIGS. 31 A and 3 IB are block flow diagrams of processes for updating directory listings 
and monitoring category objects using service objects and partner servers. 

FIGS. 32A, 328, and 32C are block flow diagrams of processes for use of authentication 
service objects. 

30 FIGS. 33 A and 33B are block flow diagrams of processes for use of public key 

certificates. 

FIGS; 34A and 34B are block flow diagrams of processes for use of classified ad siervice 
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objects and partner servers. 

FIG. 35 is a block flow diagram for a process for monitoring classified ad listings. 

FIG. 36 is a block flow diagram for a process for structuring and optimizing automated 
data exchange using a conununications object system. 

FIG. 37 is a block flow diagram for a process for creating payment accounts using service 
objects and partner servers. 

FIG. 38 is a block flow diagram for a process for executing payment transactions using 
service objects and partner servers. 

FIG. 39 is a block flow diagram for a process for returning a transaction receipt using 
service objects and partner servers. 

FIG. 40 is a block flow diagram for a process for anonymous reporting using service 
objects and partner servers. 

FIGS . 4 1 A and 4 1 B are block flow diagrams for processes for submitting feedback using 
service objects and partner servers. 

FIG. 42 is a block flow diagram for a process for multuser editing using single-user 
v^ions of the combined provider/consumer program. 

FIG: 43 is a block flow diagram for a process for coordinating fax document delivery 
using a conununications object system. 

FIG. 44 is a block flow diagram for a process for coordinating physical package delivery 
using a communications object system. 

FIG. 45 is a block flow diagram for a process for coordinating telephone calls using a 
conununications object system. 

FIG. 46 is a block flow diagram for a process for scheduling telephone calls using a 
conmiunications object system 

FIG. 47 illustrates an object-oriented user interface of a provider program of FIG. 1 
according to an embodiment of the present invention. 

■. 

DETATLRD nF<;rT^jpTjn|si 

SYSTEM OVFT^Vipw 

There is illustrated in FIG. 1 a first embodiment of a system of the present invention 
which automatically updates a database in a consumer computer with information from a 



.9732251 A1J.> 



-16- 

provider computer. Numerous providers and consumers exist in the system of the present 
invention. However, since all communications can be separated into transfers between a single 
provider and consumer, the design land op«^tion of the system is illustrated with only one 
provider and one consumer, except as otherwise iibteA As illustrated in FIG. 1 , a provider 
5 computer 1 includes a provider database 1 1 of communications control information which it 
desires to disseminate or make accessible to one or more consumers. A consumer computer 2 
includes a consumer database 21 of communications control information received irom providers 
and stored by the consumer. The organization, smicture, and content of the provider database 1 1 
and consumer database 21 aire discussed below. The provider computer 1 is connected through a 

10 communications network 3 to the consimaer computer 2. Any communications network 3 may 
be used to connect the provider computer 1 and the consumer computer 2, including direct 
network connections, server-based environments, telephone networics, the Internet, intranets, 
local area networks (LANS), wide area networks (WANS), the World Wide Web, other webs, 
and even transfers of data on physical media such as disks or computer-readable paper outputs 

15 via postal communications networics. The particulars of the communications network illustrated 
as preferred enabodiments are not linuting features of the inventionrHowever;^ Internet and 
World Wide Web provide existing capabilities between coihputers sufiicient:to provide the 
necessaiy connections. For this reason^ .the description oftheipresent invention is based on this . . 
communications medium, which should be understood to be used for purpose of illustration only. 

20 Organization and operation of the Internet and conununications over the Internet are discussed 
generally in Kris Jamsa and Ken Cope, Internet Prop-amming (1995) and Marshall T, Rose, Ifae 
Imgmet Message: Closing the Book with Electronic Mail (1993), which are incorporated herein 
by reference. Communications over the World Wide Web are discussed generally in John 
December and Neil Randall. The World Wide We h Unleashed (1 996), which is incorporated 

25 herein by reference. Additionally, the illustrated embodiment is not limited to the specific 
networics known as the "Internet" and "World Wide Web", but relate to internet, intranet and 
web networks generally. A specific feature of this invention is that it is easily adaptable to 
control and automate conununications via any type of communications network. In addition, it 
can select a preferred communications network and message encoding format to be used for a 

30 specific commimications transaction, as fiirther described below. 

As illustrated in FIG. 1 , there are two principal methods for information transfer in a data 
conununications system, both of which can operate tiirough the Internet. First, a ''pushing" 
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method transfers infonnation from the provider computer 1 directly lo a kiiOWn cohsunief 
computer 2. An example of such a system is e-mail. So long as the consumer's address is 
known, the infonnation can be routed through the communications netwdrk directly to that 
recipient; . For the pushing method, the provider must know the consumers who want to receive 
5 the infonmation. The provider must also know how to address those recipients in th^ 
conununications network. 

The second method, referred to as "pulling'\ occurs when the consumer computer 2 
requests and initiates a transfer of information directly from a provider computer 1 or from 
another server computer 32 located on communications network 3 on which a copy of the 

JO infonnation has been placed for distribution. An example of such a distribution server 32 is 
_ when a copy ofthe infonnation is placed on a web server and accessed by the consumer 
computer 2, In the pullmg method, the provider and the provider computer I or disttibution 
server 32 do not need to know ab initio, the identity or location of consumer computers 2. 
Ratiier, the consumer computer needs to know die location of the provider computer 1 or 

15 distribution server 32 and the location of the desired information to be accessed on such 
computers. 

Basig Operation of Programs for Comniunicatinn<: 

Appropriate programs executing on the provider computer 1 and the consumer computer 
2 perform tiie fimctions necessary to transfer, maintain, and update the infonnation at both 

20 locations. A program represents a set of stored instnictions which are executed in a processor of 
tiie computer to process data, uansmit and receive data, and produce displays. The provider 
program 12 operates to transmit changes in infonnation stored in flie provider database 1 1 ax tht 
provider computer 1 . When changes are made to tiie infonnation and the database, tiie provider 
program 1 2 operates to disseminate tiie changed information through tiie communications 

25 network 3. In tiie pushing metiiod, tiie provider program 12 transmits die changed infonnation. 
for example through e-mail, to the consumer computers 2 of all intended recipients. In tiie . 
puUing metiiod, tiie changed infonnation is stored on a distribution server 32, such as a web 
server, which tiien can be accessed by the consumer computer 2. Any type of distribution ser^'er 
• may be used, including network file servers, FTP servers, gopher servers, and so on. The type of 

30 distribution server used is not a limiting feature of the invention. The consumer program 22 will 
typically .poll tiie distribution server 32 to detennine whetiier the infonnation has changed. This 
polling operation can be as simple as issuing a Web server HTTP file date request and comparing 
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this with the fil&date of the last update. Polling is controlled by the infdntiddon tr^nsfeii^ 
the provider.program to the consumer program as further desbribd below. Upon receipt of 
changed information, the consumer program 22 operates to perform certain functions with regard 
to that changed information. Principally, the information is stored in consumer database 2 r on 
5 the consumer computer 2 for future reference and usage in coiitrolling and automating * 
communications between the consumer and provider. Furthermore, the inifdrmatioh may be 
presented to a user at the consumer location, so that the user will be notified of the changed 
information. The information can be presented in a number of manners, including display or 
printing by the consimier program, sending an e-mail or voice-mail message to the user, paging 

10 the user, and other notification methods. 

Since the provider knows vAm the changed information is and how consumers would 
likely prefer to be notified of the changed information, the transmitted information can include 
instnictions on how the consumer program 22 should process the information for purposes of 
notification. For example, information from a provider may include the provider's telephone 

IS number. If the telephone number changes, the provider needs to supply everyone with whom it 
does businesS'With the new number. . The present invention provides a' simple mechamsni'fbrr^ 
carrying out such a data trai^fer, and of controlling which consumers receive overt notification^ 
When the telephone number is changed in the distribution database at. the provider. computer I; 
the information is transferred to the consumer computer 2, . through either the push or pull 

20 method. Upon receipt, the consumer program 22 will process the changed infomiation and store 
the new telephone number in the consumer database 21 for later access by the user or by other 
programs operating on the consumer's computer 2. At the consumer computer 2« the consumer 
may or may not be interested in overt notification of the new phone number; this depends on the 
consumer's relationship with the provider and how often and in what manner the consumer 

25 makes use of the phone number. This invention provides a way for notification to be 

cooperatively controlled by both the provider and consumer through the use of notification 
elements, which are described below. 

Additionally, receipt and storage of the new or updated information can trigger other 
actions, such as automatically forwarding the information to another consumer, exchanging data 

30 with the consumer database 2U sending an automated response to the provider, or sending a 
message to another software program on the consumeir^s desktop. Again, this invention provides 
a means for such actions to be cooperatively controlled by both.the provider and the consumer 
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througfa the use of receipt methodsv which are discussed below. 

The infonnation stored in the consumer database 21 can also include data, metadata, and 
iiistructions to be used by the consumer program 22 for coh^^ 

communications between the provider and consumer. Agaiih, becisiuse the provider of the 
5 infonnation knows what conununications response options are available to the coiisiifhers of the 
,^ information, the provider can include the necessary data, metadaitat, and instructions to Simplify 
. and automate specific responses fioin the consumer to the provider: For example, the provider 
can include Web URL (Uniform Resource Locator) links to Web pages or forms on the 
provider's Web server. Or, the provider can also include special forms to b6 processed by the 
10 consumer program 22 that allow the consumer to automatically or semi-automatically transfer 
, data from the consumer database 2 1 back to the provider. Examples iiiclude product order 
. .. forms, survey forms, customer service request forms, scheduling forms, etc. 

In the most general case, the provider knowis what communications networks, network 
addresses, languages, encoding formats, data structures, and other comthunications processing 
15 data and methods are supported by the provider. Thus, the provider can include in the transferred 
infonnation the data, metadata, and instructions necessary to control and coordinate general 
communications fi-om the consumer to the provider or to parties related to the provider. For 
example, data, metadata and instructions in the transferred information can be used by the 
consumer program 22 or other computer programs running on the consumer computer 2 to 
20 automatically format, compress, encrypt, address, and transmit copies of a word processing 
document, spreadsheet, database or database query, or other computer file format. Corresponding 
data, metadata, and instructions in the provider program 12 can control and automate the 
reception of the received message, including decryption, decompression, notification of the 
provider, and acknowledgment of receipt to tfie consumer. The same control technique can be 
IS applied to tiie execution of real-time communications, such as telephone calls, 
- videoconferencing, or whiteboard applications. 



HTML and HTTP Server Pr ogram Fonnat 

Aldiough any kind of data conununications network and any kind of user interface can be 
. used, tile system can be constructed to work witii existing Internet or World Wide Web protocols 
for data conununications and display. In particular, the provider prograih and tiie consumer 
program can be designed to use HyperText Mark-up Language (HTML) for display and editing. 
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HTML is discussed in Internet Request for Gonmiefii No; 1 866, v^ch is incorporated hettin by 
refeience. The use of HTML allows links to be made to other transmitted iHfonnation or to other 
information accessible any^ere on the World Wide Web. Also, HTML forms can be used as an 
input mechanism. Standard Internet protocols for accessing the Web can also be used for 
5 accessii^ the information in the provider or consumer dat^xases: To do this; the provider" • 
program and consumer program are designed to emulate a Web HypefText Transfer Pirdtocol 
(HTTP) server. Then, any Web browser program confonnihg to the HTML/HTTP standard can 
generate Uniform Resource Locator (URL) requests to retrieve information from the provider 
and consumer programs and databases. A Web browser program is a set of instructions which 

10 causes the computer to execute information requests to various kinds of servers. The servers ' 
responded by transiFerring HTML files or other data files back to the browser program for 
display, processing, and storage. Protocols or formats other than HTML/HTTP can be used in 
the same marmer, with an appropriate interface program for requesting, receiving, processing, 
and displaying data in accordance with the selected protocol or format The operation of the 

15 provider and consumer programs in coimecdon with the Web browser program is illustrated in 
FIG. 2. Since the providerand .consumenprograrns.operate.identically^in th^^ 
operation of the consumer program will be discussed; : 

As.illustrated inFIG. 2, the consumer^program 22.can.be:constructed to operate as atstate 
machine in connection .with a Web browserprogram SO.l Thie consumer program 22 generates 

20 and outputs a first HTML screen (step 53) to the Web browser. If necessary it also issues an 
operating system call such as a Windows DDE request or Maciiitosh AppleEvent to the browser 
to accept this HTML file. It then waits for an HTTP request fiom the Web browser program 50. 
The HTML screen can include informajtion having one or more different types of displayed 
information, namely, text, graphics, hyperlinks, and forms. Text and graphics refers to 

25 information which is only viewed by the user. Hyperlinks associate specific text characters or 
graphics display locations with specific URL requests. Forms provide locations for inputting 
data such as text, numbers, checkboxes, and '*radio buttons" to be acted upon. Hyperlinks and 
forms allow HTML documents to be used for all program operations including menus, editings 
reports, and error messages. The Web browser program 50 displays the HTML page received " 

30 from the consumer program 22 (step 54). The user operates on the displayed page in the same 
maimer as for any information accessed tl^ough the Web browser program 50. The user can 
review the text or graphics, manually input a new URL request into the Web browser's URL 
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input field, chose a hypertext link to. automatically generate a URL request, or complete: and 
submit a form. The Web browser program; typically, can also be usedto move forward arid 
backward through previously recdved screens. Each of the usef's actions, except revie>ving text 
and graphics, results in a URl, request being generated. The URL request is sent to the (Jbnsumer 
5 program 22, acting as a Web server (stept$5).^>This consumer program processes the URL request 
, to determiTO! \irtiether it refers to a document or a method (step 56). If the URL request is for a 
doomient, the consume program generates the new HTN4L page and sends it to the We^ 
browser program (step 53). If the request is for a method, then the method is executed using any 
additional data supplied in the URL (step 57). After the method has been executed, the 
10. consumer program generates a new HTML page based uponthe results of the method. 

The user enters information to be operated upon or stored by the consumer program 
through the use of HTML forms. If the HTML page generated by the consumer program (step 
53) includes a form, then the user can enter information in designated locations in the form. 
When the information has been entered, the form is submitted by selecting a button on the page, 
15 and a set of program insmictions (method) designated by this button is executed to process the 
inputted informaUon. Many browser programs can cache HTML documents, so tiiat a user could 
have several forms open at one tune. Since the consumer program works as a state machine, it 
expects the last form generated to be the next one returned. If the user svatches the order of the 
forms, a state error could occur. To prevent errors, each form produced by the consumer 
20 program can be provided with a stete version value. If the version value of the returned form 
does not match the current state of the consumer program, then an error message can be returned 
Father than processing the forms Out of order. 

Alternatively, the provider and consumer programs 12, 22 could include separate native 
..... interfaces which include the display and processing functions found in a browser program, as 
25. well as the ability to provide additional functionality, such as that available in advance graphical 
, . user interfaces like those of Microsofi Windows. Wmdows 95. and Apple Macintosh operating 
systems. The use of an object-oriented graphical user interface will be specifically discussed 
below. The provider and consumer programs 12, 22 may also call other Web helper applications 

or "applets", such as those produced with Sun Microsystem's Java programming language or 
30 , other programming languages, to provide additional interface functions. 

BASIC DATA STRtirTTIT?T?<{ 

Information can be stored in the provider and consumer databases 1 1, 21, transferred 
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between the providerand consumer programs 12^ 22, and processed by these programs in a 
. variety of ways. The use of software objects imdbbjectK>rie^ 
their ability to encapsulate data and methods fat operatii^ on that data in a single structure, 
provide certain degrees of functionality which are useful in the storage, transfer, and processing 

5 of information. For example, by iisiiig objects for tiaiismission 

files, and an object-oriented database for storage of these files, the received object can be stored 
by the consumer program 22 in its database 21 without haviiig 16 disCoiuiect and stoie the' 
object's variables and methods independently. In addition, the data and methoBs of this object 
can be made available to other objects in the database or program for processing operations. 

10 Object oriented data-structures, databases, programs, and processing are generally discussed in 
Orady Booch, Object Oriented Aimbsis dOd QfiSigO with A pplications. (2nd ed 1 994) and James 
Rumbaugh, Qbiggt-Oriffltgd ModPling and Dssign (l 991 ), which are incorporated hereiri by 
reference. Thus, the following description of a preferred embodiment will discuss the use of 
objects. However, other niethods for storing, transferring, and processing information, such as 

15 relational databases^ binary files, or procedural programs, cotild be used. . 

As discussed.above,:fte:providerxornputer :l. includes apro database 1 1 operatedion 
by provider program; 12; and the con5umer:computer:2 includes a consumer-database 21 operated 
on by consumer program 22. However, since ^provider*' and **consumer** are merely ftmctional 
distinctions,:jn a preferred embodiment,:a:single compmer and computerprogram would be able 

20 to operate as a provider computer 1 in executing instructions of the provider program 1 2 and as a 
consumer computer 2 in executing instructions of the consimier program 22. In this instance, 
only a single database may be used, if desired, to hold all of the data for transmitted objects and 
for received objec^; The database structures described below could apply to a single database, 
or to separate databases if the programs operated separately. For ease of reference in describing 

25 operation of the provider program and the consimier program, separate databases will be 
. illustrated. 

FIG. 3 uses a istandard object-oriented notational format to illustrate an embodiment of 
object classes in a single database 100 of the present invention. As shown in the global 
preferences object class 103, each object class includes three parts: an identifier 103 A, an 
30 attribute section 103B, and a method section 103C. The method section 103C is used to perform 
operations on the attributes of the class. Class associations are shown with connecting lines. A 
plain line shows a one-to-one association. A line terminating in a solid dot shows a one-to-many 
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A 'ine temmatmg in a open dot shows a optional (zero or one) associatibri A 
diamond at the start of a line shows an aggregation association, i ;e., the higher class cohtaiiis the 
component classes. Inheritoice between classes is shown with a branching line. Only certain 
attributes and methods are shown in object classes; many others have been omitted for claiity . 

S Ctass Overview 

There aiie siSivfen principal object classes: communications objects 110, recipients 1 20, 
niles 130, meth6ds 131, pages 132, eleiiients 133, and type definitions 134. Communications 
objects are the primary data structure transmitted froih the provider program to the consumer 
program to con&bl cdmiiitinicatidhs between the provider and consumer. Like any software 

10 object, a communications object consists of attributes and methods. The type definitions class is 
• used together with the elements and pages classes to specify the attributes of the communications 
object. The methods class and rules class are used to specify the methods of the communications 
object. By using separate object classes to defme the attributes and methods that will be included 
in a particular communications object instance, a wide variety of communications objects can be 

15 created and managed within the same system. 

Recipients include all the consumer computers 2 receive a copy of the 
communications object via push distribution, or the distribution servers 32 who receive a copy of 
the conununications object for pull distribution. 

The mles 130, methods 131, pages 132, elements 133, and type definitions 134 classes 
20 are all special contamer classes of the rule 140, method 141, page 142, element 143, and type 
definiUon 144 classes, These special container classes are used to facilitate the rendering of an 
instance of a conununications object in the object markup language used for object transmission, 
'as described fiirther below. For this reason the descriptions following will discuss only the rule 
140, method 141, page 142, element 143, and type definition 144 classes. Collectively this set of 
25 classes will be referred to as the "component" classes of a communications object. 

Tvpe Definiti^in^ 

The type definition class 144 is used to define the various data types which may be used 
in the elements of a communications object. Type definitions can be of primitive type 154, 
aggregate type 155, or composite type 153. The inheritance tree for the primitive type 154 class 
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is shown in FIG. 4. Primitive types can include tte cdnventiohdi bottom-level data primitives 
supported by most piograroming languages, siich as daties 181, floating point numbers 1 82, 
logicals 184, integers 185, binaries 186, etc. Text 189 is a oonistraineid forini of binary 186. 
Range 1 88 is a multiplicity of other inimitive data types, such as array. As shown in FIG. 3; 
5 a^regate types 155 rq)resent a multiplicity of primitive types 154, such as ah array. Composite^ 
types 153 represent a container of primitive types 154 or aggregate types 155 that is useftil in a 
communications context . For instance, a composite type might be PhoneNumber. A composite 
type 153 is composed of one or more fields 152 which each contain priniitiye types 154 or 
^gregate types 155. For example, a composite type PhoneNumber may include fields for usage, 

10 country code, area code, number, extension, and notes, each with its con^ondi^^ •• 
type. A field 152 may also contain another composite type 153. In this way composite types can 
be nested. For example, a composite type BusinessCard could contain composite types Identity, 
PhoneNumber, PostalAddress, EMailAddress, and ContactNotes. Composite types are further 
explained in the discussion of elements below. 

15 . Type definitions provide a powerful tool for structuring the data included in a 

communications object, object. update, or. object message^iFhis structured datapr^ the ^ 
common "frame of reference".necessaiy to automate communications operations between a - 
provider and consumer.. It also allows'Communications:objects toicall:eachi6tber:S::methods;>and * 
for other software programs to call the methods contained in communications objectSiStored in^ 

20 the consimier database 21 . The latter technique requires the use of an Applications Programming 
Interface (API) which will be further discussed below. 

Ekmfiois 

'"Elements"' are the primary attributes of a communications object. An element 143 might 
be a phone number, a postal address, an e-mail address, a text field, and so on. As illustrated in 

25 FIG. 3, an element has data of a composite type 153 with a corresponding composite value 163. 
A composite value 163 is composed of field values 162 in the same way a composite type 153 is 
composed of fields. 152. For instance, the field values for the composite value PhoneNumber 
corresponding to the composite type PhoneNumber described above could be "voice, . 101 88, 
206, 812-6000, xlOl, Business hours are 9 - 6.daily M-F". As with fields 152, field values 162 

30 are either an agjgregate value 165, primitive value 164 or composite value 163. The value class 
161 represeiits an abstract class inherited by the aggregate value 165, primitive value 164 and 
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composite values 1 63 classes. Aggregate values 1 65 represent a multiplicity of primitive data 
values, suph as on airay. Primitive values 1 64 contain the values corresponding to the loWest 
level primitive types. These are shown in the continuation of the class hierarchy in FI©; 4. 
Primitive values include datjC values 171, floating point number values 171 nil values 173, 
5 logical values 1 74, integer values 1 75, and binary values 4 76, Text valu^ 1 79 are a constrained 
form.of binaiy values 176...Logjcal values branch into true values 177 and false values 178. 

Many elements with defined composite data types and coiriposite values are specifically 
usefiil in the context of communications automation. Standard element composite types can 
include standard types of contact information that might typically be shared between providers 
10 and consumers in tiie context of a communications relationship. These include names, titles, 
phone numbers, fex numbers, postal addresses, e-mail addresses, URLs, and customer numbers. 
Nested composite types, such as tiie business card, allow for powerful combinations of smaller 
composite types. 

Otiier element composite types are useful for tiie storage, transmission, and display of ' 
15 communications content between the provider and consumer. Elements of this type include text 
blocks, graphics, and HTML^ HTML elements are especially useful in the preferred embodiment 
as they can contain standard HTML documents \;*ich the consumer program 22 can pass 
directly, or witii minor modifications, to the Web browser 50 for display. This allows the 
provider to control the appearance of data on all or a portion data being displayed, and also 
20 allows tiie provider to include URL links to the provider's Web server or any other related Web 
documents. These links can be activated immediately by the consumer when viewing the 
conmiunications object using tiie Web browser 50 just as witii conventional HTML documents. 
HTML elements may also include the provider's own HTML forms for acquiring infomiation 
from the consumer when the object is transferred. Just as nested composite types of contact data 
25 elements can be combined into more comprehensive types such as business card elements, nested 
composite types for communications content can be combined into more comprehensive types 
such as message elements. Message elements combine text headlines with graphics, HTML, and 
otfier body content into full multimedia messages which can be filtered, sorted, and displayed by 
the consumer program 22. 

30 Elements 143 may also be associated with meUiods 141 onniles 140. This is particularly 

useful for data exchange elements, which control the process of exchanging data between tiie 
consumer program 22 and tiie provider program 12 or anotiier server program. Two specialized 
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types of data exchange elemmts are useful for controlling the trao^ission of data extetTial to the 
provider database 1 1 . Attachinent'elements allow a provider fo specify external files, objects, or 
otho- data stored in the provider's local or network cdmputixtg environment to be included in the 
transmission of a communications object, communication^ object update, or message object: 
5 Query elements allow a provider to execute a query against aiocal br.network database and have : 
the results included in the transmission of a communications object Data exchange elements, 
attachment elements, and query elements will be furdier explained in the description of data 
exchange control below. 

Another category of element composite types is link elements. Link elements within a 
10 commtinications object are the equivalent of URLs within a Web document They creaite 
associations between different elements of an object, different pages of an object or different 
communications objects. A link element can also be a URL, linking the element to aiiy Web^ 
page or other resource available on the World Wide Web. By associating a link element 143 
with one or more link methods 141, even more power&I "link conq>onents** can be created. 
15 Component objects and link components will be explained further below. 

Specid.element:compositetypes,,called preference elemente^^^^ 
commimications object processing.' Preferenceelements specify object attributes' that are / ^ 
editable by the.consimier.' . For instance, a preference element.of a composite.type 
Refreshlnterval.could govern the polling interval used for object updates using the pull method: 

20 of updating. An element of type Refreshlnterval can consist of three fields 152: Minimum, 
Maximum, and Sening, all of which could be primitive integer values representing days. The 
Minimum field specifies the shortest allowable refresh interval (to help reduce the load on the 
provider's Web server), the Maximum field specifies the longest refresh interval (to limit the total 
time one full object update cycle can take), and the Setting field specifies the acmal interval to be 

25 used (the provider's recommended setting would be used by default). The provider would 

initially fill out these three fields, then the consumer would be able to edit the Setting field within 
the Minimum and Maximum allowed. (Enforcement of this requirement could be provided by a 
rule 140.) 

Another example of a preference element is a notification element. Notification elements 
30 are used to control how a consumer is notified of new information when the object, object 
update, or object message is transferred. The fomiat and structure of notification elements are 
discussed below in connection v^th the special processing notification elements receive. Any 
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other cpnsimierredit^bje prefCTence regarding communications object attributes or method 
processing can be expressed as an. preference ele^ Preference elements receive special 
processing by the consumer program 22 and storage in the consumer database 21 : which will be 
further described below. 

5 , In addition to its comppsite Q^ and composite value; each^element 1 43 includes 

standard attributes such as system ID, name^ description, version value, NewFlag, and HbldFlag, 
The system ID is a unique identification value in the database 100. Identification number 
assignments throughout the database are discussed below. The name is a label used to identify 
the elonent to the provider or consumer. The version value is used to coordinate updates each 

10 , time the element is chaqged. The NewFIag is set to TRUE each time an element has been 

changed by a provider so tiiat new information can be indentified for distribution by the provider 
program 12, and identified for updating when transferred to tiie consumer program 22. The 
HoldFlag is used to identify changed elements which are not yet to be distributed. The structure 
and content of elements may be more fully understood in connection with tiie description of 

15 notification elements discussed below. 



In order to organize the many elements 143 which can be contained in a communications 
object 1 1 0, one or more container classes may be desired. Container classes allow the grouping 
of elements for purposes of display, editing, or otiier program operations. Container classes are 
20 also useful for distribution control, which will be discussed below. Different types of container 

classes can be implemented, and container classes can contain other container classe FIG. 3 
illustrates the implementation of one primary container class: the page class 1 42. A page 
-• -contains one or more reference instances 1 46 which associate elements 1 43 with tiie page. 
/ References may contain attributes such as DisplayOrder which control the display order of the 
25 elements on the page. Each element 143 must assigned to at least one page 142 in order to be 
transmitted with an object, however an element may be included on more than one page 142. 
Standard page attributes are similar to the standard element attributes, i.e., SystemID, Name^ 
Pescription, VersionNimiber, NewFIag, and HoldFlag. 

Methods 

30 The method class 141 is a form of metadata used to store methods which may be included 



BNSOOaO: <WO 9732251A1_I_> 



-28- 

iri a eoinmunicaii6n& object ihst£ih(£ v/tieh it is truisferred to a cos^umeh tlbese methods should 
notbe confused with lihe methods belonging to eacb'of the other t)bject classes in the system. A 
medfiod object is primarily a medianism for storing a mediod in the database for later inclusion 
in a conununications object instance, at vAnch time the method becomes a formal method of the 
5 communications object Conununications object methods se biie of the most-powerful aspects 
of communications objects. They allow the provider to specify processing instructions which 
will execute on the consumer's computer when certain conditions exist in the cbh^iiTner program. 
For example, vAita a commumcadons object is first received by the coiisiimer program 12, a 
"receipt method" can automatically execute to return an acknowledgment message to the 
10 provider with information about that consumer transferred from the consumer database 21 . 

A second purpose of instances of the method class 14 1 is to execute procedures in the 
provider program 12 or consumer program 22. These procedures can be instructions involved 
with the process of creating and publishing commtmications objects, or they can be instructions 
to be executed when a inessage object is received from a conununications object. Message 
IS objects are discussed fiirther below. 

Instances of the method class 141 may implement communications object methods in ; 
several ways.- The method can simply be a c^l to execute a system method included in the 
consumer program 22. The method can be actual instructions included in the object as program 
code in an executable format or an intorpretable fomiat, such as a script format. The method can 

20 be a call to the methods of another communications object located in the provider database 1 1 or 
consmner database 21 . The method can also be a remote procedure call to another object or 
application located elsewhere on the constmier's computer or on a commtmications netwoik 3 
. accessible from the consumer program. This remote procedure call can be executed at the remote 
computer, or it can be downloaded by the consumer program for local execution. The 

25 application of commtmications object methods to automating operations in the provider program 
12 or consumer program 22 will be further discussed below. 

Methods 1 4 1 may be of specialized types. Method types can be detemiined by a type 
attribute, or by method type subclasses to which methods 1 4 1 are associated. Methods types 
include receipt methods, public methods, private methods, and system methods. 

30 Rules 
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Rule^ 140 work in conjunction with methods tp provide the Qpc?rational functionality of a 
communications object syste^L.Rul^s allow the provider database 1 1 and consiuner database 2 1 
to operate as active qbject databases, capiable of .initiating conununications, database processing, 
or other procecjures .feased on time, system variables* system events, or other conditions. Rules 
5 also supply cpnsttBints un^er which methods operate. The usage, of rules to control the operation 
of an active pjbject database i$ discussed, generally in Jennifer Widqm and .Stefano deri. Activg 
Qj^aJfflSg SsiSSSIQS ( 1 996), which is incorporated herein by reference. 

Rules 140 consist of one or more conditions to be tested against. Riiles 140 are associated 
with methods 141 to execute when the conditions are met. Rules 140 are typically expressed in 

JO boolean logic using standardized query languages or other appropriate formats. Rules can govern 
the behavior of individual communications objects, groups of communications objects (such as 
all objects from a particular provider), all objects in the database, or general system actions. 
Examples of common processing actions governed by rules include backing up the database after 
X days or X number of changes, deleting or proposing for deletion communications objects that 

15 have not been accessed in X days, archiving X number of previous copies of a communications 
object or object component, using X amount of system resources when Y conditions are present, 
and allowing X number of communications objects or recipients under a particular software 
license. Rules may be understood fimher in the discussion of cortunimications object control 
functions below. 

20 Comniunicfltions Ohiectg 

Conununications objects 110 are the highest level data structure because they serve as the 
container for type definitions, elements, pages, methods, and rules. Each of these is a one-to- 

°*™y relationship. A type definition 144, element 143, page 142. method 141, or rule 140 must 

be assigned to an object 1 1 0 in order to be transferred to a consumer, however each type 

25 definition, element, page, method, or rule may be included in more than one object 1 1 0. 
Communications objects have many of the same standard attributes as elements, pages, and 
methods, i.e., SystemID, Name, Description, VersionNumber, NewFlag, and HoldFlag. In 
addition communications objects also have attributes that apply only to communications objects 

^ as a whole. These attributes can include the markup language version used to generate instances 

30 of the object, the objects' age, and the number of published updates to the object, receipt 
acknowledgment preferences, and other universal attributes. 
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Commtihications objects can be of spfkiaihtd typesV lliere are^ approaches for 
accompUshmg thi^. One ^pib^ is to define communications ob^ types using a special 
CdmniObjedtType element included within or lefofenced by the commtmicatibns object itself. 
The preferied embddimeht of ttie present invention is to define communications object types as 
5 subclasses of the conimumcations object 'supescla^:11i illustrated ill FIGV 1 7. ~ 

Primary communications object type classes include message objects 1 10, composite objects 
81 U component objects 812, synthesized objects 813, and service objects 815. Each of these 
subclasses will be further discussed below. 

RggjpiiCTtS 

10 llie Recipient class 1 20 is used to detemiine the distribution of a communications object. 

. Each communications object 1 10 is associated with one or more recipients 120 vAio receive an 
instance of the object v/hen it is first created or when changes are made to it Recipients are of 
two types: consumer programs 22, or distribution servers 32. A distribution server 32 may also 
be represented by a distribution service object Distribution service objects are fiirther discussed 

15 below. Transfer of communications objects -1 10 to both types of recipients is typically- via the 
push technique. . However recipients may also be tracked in the provider^database J 1 even if they 
use the pull technique of updating via the use of receipt acknowledgmentmessages:.* 
Acknowledgment messages are fiirther described below. The push method may involve a fiilly 
automated transfer via a communications network 3, or it may involve a manual transfer such as 

20 a file copy over a network or via a computer floppy disk. Recipient objects 1 20 include the 
attributes necessary to generate and transmit an instance of the communications object to the 
recipient. To uniquely identify recipients even when names charige, a SystemID attribute can 
used in addition to a Name attribute. System IDs are discussed below. Other attributes include 
the recipients communications network address, such as an e-mail address, the type of encoding 

25 that should be used (e.g. MIME, BinHex, UUencoding, etc.), and the maximum attachment file 
size the recipient can accept (to determine if multiple attachments need to be sent). Recipients 
120 have an association with methods 141 in order to allow different methods to be assigned to 
different recipients. An example is the communications object's update method. 
Commuiucations objects transmitted to consumers via e-mail push may use one update method, 

30 while those tnmsmitted to distribution servers may use a pull update method. &icdding methods, 
transmission methods, and other recipient-specific rnethods may also be assigned in this manner. 
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Recipients 120 also has an aggregate association with acknowledgment 121 an# page 
subscription 853. Acknpwle;<lgment 121 has a one-to-one association with communications 
objpct 1 10. Acknowledgment 121 is, wheip. consumer acknowledgment of the receipt ofa 
commpicatioxis object can. bp stored. Page subscription 853 is the mechanism by which a 
5 provider can control distribution by sppcifying^which pages are transferred to a recipient; 
Alternately, by including in coihmunications object 1 1 0 all instances of page subscription 853 
for all pages 142 associated with the object but not necessarily U^smitted to the consumer, the 
provider can allow the consumer to choose which pages the consimier vsdshes to receive. 
Distribution control is further described below. 

10 Other Clas^Pi) 

Four other classes in the database significantly involved with program operations are 
global preferences 103, report 105. folder 1 15, and event 1 16. Glpbal preferences 103 provides a 
means for storing the preferences of a provider or consumer for general operation of the provider 
progiam 12 or consumer program 22. This may mclude attributes such as the default menu to 

15 display upon program startup, the default refresh interval to assi^ to new objects, the user's 
prefwence for notification v^cn new objects arrive, the number of object archive copies the user 
wishes to keep, and other such preferences. Global preferences 103 may also include method 
preferences, such as the notification method to use when new objects arc received, the method to 
use for archiving versions of objects or object components, and the method to use for backing up 

20 the database. 

Report 1 05 is a class for storing report definitions and report display or printing 
preferences. As in many database management systems, reports may be defined by the system or 
by the user, and can include any listings, statistics, or analysis of value to the user. 

Folder 11 5 is a container class useful for grouping objects, particularly for consumers. 
25 Folder groupings allow groups of communications objects to be referenced simultaneously for 
analysis, display, sorting, searching, reporting, and transmission. Alternatively, although not 
shown, folders or other container classes can be applied to other classes, such as pages and 
elements, for similar purposes. 

The event 1 1 6 class is an abstract class defining the attribiites for scheduled events 1 1 7 
30 and logged events 1 1 8. The scheduled event 1 1 7 class is used to create a queue of events for the 
provider program 12 or consumer program 22 to execute at some time in the fiinire. An example 
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is; theipbUing opeiaddh neces^iry to update. commit the pull technique. The 

logged event 118 class is the counteipart used to create a iSg of past events. System events may 
need to be tracked for purposed 6f accumulated statistics, tracking user or conunuhications object 
activity, documenting errors, providing payment transaction receipts, etc. Scheduled event and 
5 logged event objects can be further- tmderstood in the discussion of event loops; event lo^^ing, 
and event scheduling below. 



Object Markup Language 

In order to transfer a conunimications object instance or object update instance from a 
provider program 12 to a consumer program 22, the object must be output from the provider 

10 database 1 1 into a format suitable for transport via a conunimications network 3. Any type of 
machine readable and writable format could be used; for example a comjKessed binary file such 
as that used by most relational or object-oriented database management programs. However, for 
maximum compatibility vdth communications networks 3 and oSier data processing systems, 
object instances can be written or read in an ASCII markup language,. >^iuch is a sxq>erset of 

15 HTML.,. As-with:HTML, or other standard marirap: languages siich:as''SGMLveachitem^of- — 
structured data such as an object class or container class is expressed within aset of delimiters or 
"tags!! definediin the markup.language • v. Certain classes. in.the database structure exist specifically . 
to provide the necessary container tags for other classes: For example, in FIG. 3, the methods^ 
131, pages 132, elements 133, and type definitions 134 classes are all special container classes 

20 used to provide the tags necessary to delimit the methods, pages, elements, and type definition 
sections of an object output in the markup language. Another advantage of the use of an ASCII 
markup language is that the data and methods contained in communications object may be 
rendered readable to other data processing programs for purposes of interoperability. Other 
programs may also be programmed to output such a language or a subset thereof for purposes of 

25 importing into a communications object system program. The use of an ASCII markup language 
does not preclude the use of additional formatting or encoding, such as encryption, for the entire 
object or for portions of the object 

BASIC SYSTEM PROCESSES 
System ID and Naming Services 
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^^eoape; c^^uniji^c^tiQns^p^^ their con)i>pnjrot type^^d^ ^|f^J(PCAt^vipages, 

and rnetjh[p4^ esccbai^g^. ^png m providers and. consumers, insUuici^j^ of diese 
objects. an4:C^3!|i)ponen;sii<^ to he uiiiqu^ly distinguishable in each provider database 1 1 and 
consumer database 2 1 . Name attributes alone cannot be relied upon to guarantee imiqueness. 
5 Other ijpque identifi^ nuihbering systems could be eniiployed,^suoh as the provider's or 
. consumer'? U,?. Social Secupty numbers, U.S. Federal Employer Idmtification Numbers, 
passport numbers, etc.. However, in a communications system which may be used globally, not 
all users may be assigned unique identifiers under one of these identification systems. A 
separate global identification system could be employed, such as the domam naming and e-mail 

10 addressing system used by the Internet Although not all Internet users have their own Internet 
domain names, all of them have unique e-mail addresses. However, since users can and do 
change e-mail addresses, tiiis would require that their system ID also change. The ideal 
communications system allows complete separation (or "abstraction'' in object-oriented 
terminology) of a user's communications system ID from any real world names or physical 

15 communications network addresses with which the user is associated. In this way, users can 
change any of his/her names or physical communications network addresses while still 
maintaining complete continuity of his/her communications relationships. In addition, any 
changes to the user's name or physical communications network address can be automatically 
distributed by tiie user's communications object(s) to all other consumers with vfhom the user has 

20 a communications relationship. 

To achieve this objective, a preferred embodiment of the present invention assigns a 
unique system ID value to each unique communications object and communications object 
componwit This function is the equivalent of an automatically-generated unique key field ID in 
many conventional database management systems. This objective can be achieved in several 

25 ways. A first technique is to employ an algoritiun that uses system state information together 
with daU unique to the computer on which it is being run to produce system IDs whose 
probability of uniqueness is so high tiiat for practical purposes they can be treated as unique. The 
use of such algorithms for creating globally unique object IDs is discussed generally in Kiaig 
Brockschmidt, Insidfi OLE ( 1 995), which is incorporated herein by reference. Standard industry 

30 algorithms and functions that have been created for this purpose include the Universal Unique 
Identifier (UUID) specified by the Open Software Foundation (OSF) Distributed Computing 
Environment (DCE) documentation. This algoritiun is fully documented in Steven Miller. 
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Specifieatforiv Vet^iQh QSF TXl .01 1 Yl992\ which is inc6ip6rated here^^^^ use 
of a gerieraliy aoc^tisd ihdiistry UUID has tfie advantage ofxnaking a conuhuhicatibhs object 
identifier system directly compatible with other indiistiy standard distributed object system - 

5 specificadons. Ex^ples of siich stahdaids ihcliide the DCE^ and CORB A* s^>e61ifi^^^ firom the 
Open Software Foundation arid the OLE and DCOM specifibaiidns froih Microsoft Corporation. 

The second altmiative is to use a centralized server or set of servers to produce unique 
system IDs as required. This approach has the advantage of creating a centralized registry of 
unique system IDs. Such a registry has other applications within a cpmmimications object 

10 system, as ftirther described below. The architecture for centralized system ID assignment is 
illustrated in FIG. 5.' A central system ID server 42 contains a database of system ID assignments 
41. The system ID database 4 1 could be replicated across a group of ID servers 42 at various 
nodes of a communications hetworic 3 to improve perfonnance as the number of users increases. 
Upon initial installation, each provider program 12 or consumer program 22 sends a request 44 

IS via the communications network 3 to the ID server 42 for a unique system ID 43. . The ID server 
42 returns a response 45 to the requestingrprogram/ The requesting program theo saves the 
system ID in the provider database 1 1 or consumer database 21. This system ID 43 is shown in 
FIG. 3 as the SystemID attribute of the Database class 100. Within the database, the provider 
and consumer programs"12, 22 can include aftmction forassigning a separate unique system ID 

20 value to each instance of a commimications object 1 1 0 or any class that will become a 

component of a conmnmications object In FIG. 3, these classes include the rule 140, method 
141, page 142, element 143, and typeDefmition 144 classes. Again, this ftmction is the 
equivalent of an automatically-generated unique key field ID in a conventional database • ' 
management system. Since the provider's systeni ID 100 is unique for the entire 

25 conununications system, and since each instance of a conuniuucations object system ID 1 10 or 
any or any component class system ID is unique within the provider's database, the combination 
of these system IDs creates a hierarchical indentification system capable of uniquely identifying 
every communications object instance or object component class instance throughout the 
communications system. This unique ID for any commuiucations object or conununications ^ 

30 object component will be referred to as its UID. 

It can also be desirable to be able to assign provider jgroups withiii the coximaunications 
system. Group identifiers allow providers to be classified for purposes of program licensing 
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control, system attribute or system method acces$/peTOissions, object attribute or object method 
access peniiissions, statistics gathering, or other purposes. For example, each employee of a 
iargC: corporation would need a uplque provider syste^m ID, however the corporation would also 
need a group ID to identiiy the employee's conimimications objects as part of the corporation. 
5 The corporation may iunher desire to identify employees by subgrpi4}s such as division and 
.department. 

The system ID assignment function can be modified to provide this capability by 
including nested system IDs for each group association within the system ID database 4 1 . The 
object class model for nested systeni ID associations is shown in FIG. 6. The system ID 

10 database 250 contams any nuniber of unique system IDs 251. Each of these may in turn contain 
zero, one, or more unique system IDs that function as group IDs as shovsoi in association 255. 
. Jhis nesting of IDs may be as deep as necessary. Each system ID 251 includes a name and 
description attribute. For top level system IDs this would be the name and description of the 
provider. For lower-level group IDs this would be the name and description of the group 

15 (company, division, department, etc.). 

Each system ID 251 also includes a key attribute. This could be a password, encryption 
key, or any similar value. This value could be used in conjunction with an Authentication 
method of the system ID 25 1 to verify that the user applying for the group ID is authorized to be 
in that group. For example, a corporate administrator could establish a group ID for the 

20 corporation. The administrator would receive the initial key for that group ID. The 

administrator would need to communicate that key to each employee who would supply it in the 
request 44 (FIG. 5) to be assigned that group ID. Each system ID 25 1 can also be asisociated 
with one or more system ID category objects 252. System ID category objects can be Used to 
.establish system-wide groups useful for program liccnsmg, statistics, access permissions, or 

25 other purposes. Category objects will be further explained below. 

The system ID server 40 shown in FIG. 5 is available system-wide, and includes at least 
one sys^m ID object instance 43 in the system ID database 41 for each provider. Since this 
object instance contains the provider's name, description, and an authentication key, the system 
ID servcr-40 is a suitable mechanism to offer both system name directory services and system 

30 authentication services. These services are further described below. . 

The system ID assignment function can be further improved by using communications 
objects included with or downloaded by provider and consumer programs 12, 22 to^control the 
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accessof the providiK' and consumer plograms 12, 22 to the system ID server 42. For example, if 
a. group of system ID servers 42 was emi^loyed for peffbraiaiice or loading reasons, a 
communications object could determine the optimal, member of the server group to access. Such 
specialized communications objects are refeiTed to as service objects and will be further 
5 explained below. • - - - 

Basic Object Transfer Processes 

Besides using HTML as a display protocol, the Internet and World Wide Web also offer 
suitable protocols for accessmg and truisferring commimicatiohs objectsV A Web browser 
program SO can be used both to retrieve the communications object and display it for viewing 

10 and editing to the consumer. The transfer of an object using a Web server 32 is illustrated in 
FIG. 7. An object can be transfeired to a browser 50 as a result of a manual HTTP request by a 
user, or it can be transferred directly to the consumer program 22 as a result of automatic event 
processing such as polling. In the case of manual requests, the browser 50 issues a HTTP request 
36 to the web server 32 to receive the communications object markup file 35 which is located on 

15 the web server 32.. The HTTP request 36.can result,fit>m a URL nianually- entered :by t^^ user.or . 
through selection of a. URL link from any .Web page. Thus, providers v/ho have World Wide 
Web dociiments:can create Unks to.their communications objects in those docu^ A 
consumer.can obtain a commimications object:simply;by using.a:browser'50:to.select:the link. . 
The object itself is then transferred as a standard Multimedia Internet Mail Extension (MIME) 

20 object type ais defined by the Web HTTP protocol, in response to the HTTP request. The MIME 
type is discussed in Internet Request for Comment Nos. 1 521 and 1 522, incorporated herein by 
reference. As with other MIME objects, the browser program 50 determines whether a helper 
application exists for this type of MIME object* For a MIME type which lihiquely identifies . 
communications objects, the browser program 50 transfers the object to the cbnsimier program 

25 22 as the helper application. 

In the case of a automatic HTTP request 37 from the consumer program 22 to the web 
server 32, the same. MIME object transfer takes place, only the object is received directly by the 
consumer program 22. In either case, the transfer to the consumer program 22 principally results 
in the execution of a set of processing steps. These steps typically include decoding of the MIME 

30 object, reading of the object, and storage of the object in the consumer database 21 . The 
consumer program 22 can. also execute other processing steps based upon the version of the 
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obj^ct, th^ wi^uin^^^ for preference. cJerae^ other consumer preferences, 

anct pdier methods in the object The processes for storing aiid processing communications 
objects are disK^ws^db^^^^^^^ 

FIG. 8 illustrates transfer of an object through e-mail using the push technique. The 
5 - browser program 50 is. not u§ed foi: this function: The object may^be attached as a MIME object 
to an e-niail messs^ge 38, Qtiier attaqhmeiit or encoding ^ypies m^y be used, such as Binfiex or 
UUencodipg. Ti^^ object may also be encoded in ASGH within the text of the e-mail message 
itself. The optimal encoding method for each recipient can be selected and employed 
automatically by the provider program 12 v^dien this information is included in the Recipients 
10 (120, FIG. 3) class, as further described below. The transmission steps for e?u;h attachment or 
, encoding type may vary slightly. The transmission steps for a MIME attachment will be r 
> described here. The e-mail message is sent in the ordinary manner, using whichever e-mail 
servers and intennediaries are available (i.e., through the Internet 3), to reach the consumer's e- 
mail server 31. The consumer's e-mail program 62 retrieves the mail message from its server in 
15 the ordinary manner. Depending upon operation of the e-mail program, the attachment may be 
downloaded for storage in either an internal or external MIME directory 63, 64, or left for 
storage on the e-mail server 31, The consumer program 22 then periodicaUy polls the MIME 
directory 65, 66 or the e-nudl server 3 1 to locate objects of a communications object MIME type. 
If a communications object type is located, it is read from the storage location and processed by 
20 the consumer program as described below. It may also be deleted from the MIME storage area 
by the consumer program 22 after it has been read and processed. 

Alternatively, all e-mail from a server can be filtered through the consumer program 22. 
In this process, the consumer program 22 acts as a proxy server. The e-mail program 62 polls 68 
the consumer program 22, as the proxy server, for new mail. The corisumer program 22, in turn, 
25 polls 67 the e-mail server 3 1 . The resulting mail response is filtered for communications objects 
directly by the consumer program 22 before being transferred to the e-mail program 62. 

.Communications received via other types of communications networks can also be 
filtered for communications object transmissions in a similar manner. For example, telephone 
calls originated by a conmiunications object can carry a distinctive tone or tone series which can 
30 be recognized by a receiving consumer program 22 in the same way a fax tone is recognized by a 
fax machine. This tone could be universal for all communications object types or could vary by 
special communications object types. Once die tone was recognized by the receiving program, a 
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communicatioxlis objec^'trah^S^neg^ take piaic^ betweeti the caiiiiig provider 

pFOgtam 12 axid the receiving coosviiner prognmfi 22. this could be iised to accdinplish.the * 
transfer of commitnications objects, message objects, or other data ihdqpehdently, or to control 
or augment a voice telephony sesjsion. 
5 Cbirmtimcatidns via 

object system m the same manner. The originatihg provider program 12 can control the printing 
of envelopeis or ^closurts in a machine-readable format such as bar codes. It can also control the 
production of transportable data files such as floppy disks or tape cartridges for transport via a 
postal mail network. At the receiviiig end, the mail or package envelope or contents can be 

10 machine scanned for data that caii be interpreted by the receiving consumer program 22. 

Alternatively or in addition^ the transported data files contained in the postal mail can be read by 
the consimier program 22 to proceiss messages contained therein or to control the receipt and 
processing of iuxompanyihg physical goods or information. 

Broadcast networks such as television or cable systems can represent particularly 

IS efficient means of transmitting communications objects or object updates via the push technique 
if the consumercomputer 2 is equipped with a device for .receiving and decoding the broadcast. / 
signal. By.applying the filtering techniques described above to "listening*! on a broadcast 
network,:a consumer:program 22.can receive only the conunimications object updates intended . 
for conrniimications objects in the consumer's database^21. Because broadcast networks are - 

20 transmit-only, communications back to the provider miist be accomplished using a *'back 
channel" such as a telephone network or computer network, e.g. the Internet. 

Provider Program Operation 

As described above, the provider program 12 operates as a state machine in generating 
HTML screens and forms which are displayed by the user's browser program. The provider 
25 program 12 is used to create and edit instances in the provider database 1 1 of the object classes 
described above. The provider program 12 is also used to publish and distribute instances of 
conmnuiiications objects to one or more consumer programs 22 or distribution servers 32 through 
the communications network 3. 

FIG. 9 illustrates the relationships between various screens and.fonns produced and used 
30 by the provider program. Upon starting, an HTML page of the main menu 300 screen is . . 
generated and displayed. If the browser program 50 (FIG. . 2) is not currently operating, the 
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providcr ^rggrara 21 starts the browser program SO.anjdigenerat^ a DQEv OLE, AppleEvent, or 
siinijar Qpeiating system request to start the browser program 50 and have it display the 
requested HTML page. The main menu 300 screen lists various menu items vAiich are 
hyperlinks to pther HTNiU^ P<Pg^ containing additional menps or forpis. The menus and forms 
5 discussed with respec^ to the provider prQ^am 22;Qr;CQnt^uin$i:4)2p 21 are.pierely . 
illustra^w tlje capabilities of the sy^^. The J?atHiie§ and functions of the :sy stem, can be 
organized in pny order or hierardiy within the scre^ based menu system. Alternatively^ another 
native interface system could provide a substantially different organization. The use of a 
graphical user interface will be ^ifipally discussed below. Additionally, other fimctions and 
10 features can be added by creaitin^ other menus or forms and adding hyperlinks between the 
existing menus or forms and those new screens. Furthermore, in addition to qjecific menus, 
, various choices can be implemented on toolbars displayed on one or more of these HTML pages. 
In order to satisfy user preferences, many menus, forms, and toolbars can be editable by the user 
via preference forms or even direct HTML source editing. Such preferences may allow a 
15 different default startup menu screen, different toolbars, different menu choices on any given 
screen, different screen fonts or backgrounds, and other display or operational preferences. 

The first five choices on the main menu 300 allow the user to work with the 
communications objects, pages, elements, type definitions, methods, and rules stored in the 
provider database. The provider program is primarily creating, displaying, editing, and reporting 
20 on objects in the provider database. Therefore, the menus and forms used by the provider 

program are similar to a the menuing, browsing, editing, or reporting modes of any conventional 
database application. Initially, there are no user-defined communications objects, pages, 
elements, type definitions, methods, or rules. (System-defined cpnmnunications objects, pages, 
elements, type defmitions, methods, or rules may exist but are not editable by the user). Upon 
25 selection of one of the menu choices, a HTTP request is generated to display the requested 
HTML page. The communications object 320, page 330, element 340, type definition 350, and 
method/rule 360 forms include similar fimctions: create, edit, delete, and preview. Although the 
functions are similar, each menu has links to different HTML forms used for performing the 
fimctions on the different types of data (coniinunications object 321-324, page 33 1-334, element 
30 341-344, type definition 351-354, and method/rule 361-364). In addition to the menu choices, a 
list of the appropriate class instances from the provider database 1 1 is displayed in order to select 
die data to edit, delete, or preview. In one embodiment, hyperiinks or form buttons for editing. 
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deletiog, pre^ewirig are associai^ i^atH- ealtH data item in the list: AheniatiVely^ a single 
link to the editv delete; or pxeview fdtihs can be uised and the dsLta item can be selected Grom a list 
when the lEqspropriate fomn is displayed^ 

The create forms 321, 331, 34i, 351, 36l are respeicdvely used to create a new 

5 conomtihicaiidns object, pa^^, eiemeht, ty]% de&ufid^ or the^iod/rule instance. A form is 
displayed Having entry locatioiis to ibput the necessary attribute data and create the desired 
associations. AssociiEition choices can ^ shown as lists of the associated class instances with 
checkboxes or input fietlds for each instance. For example, when a new ps^e is created, the page 
create form 321 that creates a new instance of a page (142, FIG. 3) would include a list of 

10 commiinicatidiis objects (110, FIG. 3) to which the new page can be assigned. It would also 
includea list of elements (143, FIG. 3) that can be assigned to the page, the display order for 
these elements could be input as nummcal values in input boxes representing each reference- 
instance (146, FIG. 3). 

FIG. 1 OA shows the processing steps to be taken upon submission of a create form. 

IS Th^ steps also q)ply to submission of an editing fonn as described below. When a create form 
is submitted (step 400), the provider prograro^l 2 first detennines v^etfaer.the form.data is .valid 
(step 401 ). If it is not the provider program returns an error screen orform with information 
about the error to the user (step 411 ). This error screen may include a form for correaing the 
error, or hyperiinks to other forms where the error can be corrected; Once a form passes the\ 

20 validation test, the provider program then determines whether the form is a create or an edit 
operation (step 402). For a create operation, the program next assigns the new instance an initial 
version value (step 403), sets the instance's NewFlag attribute to TRUE (step 404), and saves the 
instance to the provider database 1 1 (step 405). The version value is used to compare changed 
object class instances in the object reception processing. The NewFlag attribute is used to 

25 indicate a class instance that requires distribution. 

The subihission of any new or changed data in an communications object component 
class triggers the update association rule. This rule can be stored as a rule 1 40. The method 
associated with this rule is illustrated in FIG. lOB. In this method, the provider program first 
queries the provider database 1 1 for all associated class instances which contain the new or 

30 updated class instance (step 43 1 ). The program then processes each associated class instance to 
determine whether it is aheady identified ias anew instance (steps 432, 433). If the associated 
class instance is not new, the version value is incremented (step 443 ), the NewFlag is set to 
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TRUE (step 442), and the instance is stored in the provider database 1 1 (step 441 ). When an 
associated class instance becomes new, every containo- association with this mstance must also 
be processed (steps 431-433). In this way the program processes the entire tree of all class 
instances which contain the newly created class instance, inoementing version values and 
5 markmg them as new. This is necessary to ensure the complete distribution of all associations to 
. any new or changed class instances. When all containw class associations have been updated, the 
next HTML screen is generated (step 435). 

The edit forms 322. 332, 342, 352, 362 shown in FIG. 9 permit the editing of instance 
attributes and associations in the database of the appropriate class. For example, the 
10 - communications object edit fonn 312 wUl list the pages which cuirenUy exist in the database and 
therefore can be assigned to the object. A submitted edit form 322, 332, 342, 352, 362 is 
r; processed according to die steps illustrated in FIGS. lOA and lOB. A test for an edit form is 
performed in step 402. From this point there are only two differences from create form 
processing. First, iftheNewFlag attribute ofthe edited class instance is already TRUE (step 
15 4 1 2), this means the instance has been edited since the last distribution operation. In this case, 
the update association method need not be performed. The edited instance can simply be saved to 
toe database (step 425) and the next HTML screen generated (step 426). 

Second, edited instances do not necessarily replace the previous instance v*en stored in 
the database (steps 415, 425). Multiple versions of object instances may be maintamed in the 
20 database so that the user can revert to previous data. The number of previous versions stored is 
controlled by a global preference attribute (103, FIG. 3) or a communications object preferences 
attribute (127, FIG. 3) and one or more archivmg rides 140. Each time an edit form is submitted, 
the archiving rule 1 40 is triggered. Using the appropriate preference attribute, the archive rule 
determines if the prefenred number of previous versions ofthe communications object (1 10, FIG. 
25 3) are already stored in the database. If so, then the oldest version is deleted when a new version 
IS stored. If not, the new version is added to any previous versions that exist. Data archiving 
control is further discussed below. 

The delete forms 323, 333, 343, 353, 363 shown in FIG. 9 are used to remove chiss 
^ instances from the database. The form can require confirmation that the selected instance is to be 
30 .^deleted. Additionally, the delete fonn can provide a list of other instances ofthe same class in 
order to alloxv the selection of multiple items for deletion. Processing of a submitted delete form 
first involves executing the steps of the update association method illusuated m FIG. 1 OB. Then 
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the selectedxlass instance or instances can be deleted from the database. Instance deletion may 
follow a user preference for archiving a specified number of deleted instances, or maintaining 
deleted instances for a specified interval of time before purginjg them completely from the 
database. - 
5 The preview fomis 324, 334, 344, 354 shown in FIG; 9 provide a display of a selected 

conaraunications object, page, element, or type defmition as it would appear to the consumer, 
without editing labels or internal naming labels. This is similar to the print preview mode of a 
word processor: Submission of a completed method/rule preview form 364 executes, when 
possible, the selected method or rule to test how it would operate in the consumer program 22. 

10 The recipient form 310 accessed from the object menu 320 is used to assign the recipients 

(120, FIG. 3) who will receive each communications object. From this form the user can add or 
delete recipients associations for the selected object by the use of checkboxes for each recipient. 
The user can also choose to go to four additional forms. The create recipient fonn 31 1 allows the 
user to add a new recipient instance to the database. The edit selected recipient form 312 allows 

IS the user to edit the recipients settings for communications object distibution. The delete 
recipient form 31 3'pennitSvthe user to.delete a recipientfrom'the database:::.No: special 
processing is required when adding, editing, or deleting recipient instances since they are not a 
conununications object component.and.there are no-associations that contain them. However; 
NewFlag and HoldFlag attributes for recipients are set as described previously for purposes of 

20 communications object distribution. The preview recipient form 3 1 4 allows the user to see 
precisely how any selected communications object and its component pages and elements will 
appear to a selected recipient. 

The reports form 370 is used to create, edit, delete, and display reports ( 1 20, FIG. 3) 
from the database. Menu items link it to the create report form 371, edit report fomi 372, delete 

25 report form 373, and display report form 374. The preferences form 3 1 6 is used to edit the user's 
overall preferences (GlobalPrefs 1 03, FIG. 3) for program display and operation. 

An object is published by using the publish menu form 326. Publishing refers to the 
process of reviewing and finalimg changes and initiating distribution. When selected, the 
publish menu 326 provides a list of conununications objects, pages, elements, type definitions, 

30 methods, rules, and recipients which have been changed since the previous publishing operation. 
The items on the list can be selected, edited, and previewed in a manner similar to that under the 
respective conununications object, page, element, type definition, and method/rule menus. One 
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editing action a user might typically txdce at diis time is to set the HoldFlag attribute to TRUE. 
When this. is done, all other editing changes are preserved but the class instance will be withheld 
from distribution until the HoldFlag attribute is reset to FALSE. Once the user is satisfied that 
all the information is correct, the user selects the distribute fqm 336. This form first provides 
5 the opponunity for a final cotifirmation tiiat the new information is< ready to be published. It also 
. allows setting of various parameters relating to the distribution proce^^ One such parameter is 
the date and time the actual distribution operation should occur if it is not to take place 
immediately. Another parameter is an acknowledgment setting and acknowledgment interval, 
which are described below. Once the distribute form 336 is submitted, the communications 
10 object generation and distribution process is initiated. 

^ Basic Communications Obtect Distribution Process 

In the communications object distribution process, instances of the communications 
object (110, FIG, 3) are created and transmitted to the recipients (120, FIG. 3) associated with 
the object. This processing proceeds in accordance with the instructions on the distribute form 

15 (336, FIG 9) and the attributes and methods of the recipient (120, FIG, 3). Two different 
techniques can be used to publish an existing communications object which has been updated. 
The entire conununications object, including all of the changes, can be transmitted each time it is 
distributed. Alternatively, only the component class instances v^^ch have been changed may be 
sent. The only difference is that in the second technique the distributed communications object 

20 only contains the class instances and associations where the NewFlag attribute is set to TRUE. 
Instances and associations which have not changed are ignored. Therefore, whether the 
unchanged data is sent to the consumer program is irrelevant Whether to send a complete object 
or only changed components depends upon the complexity of the object and the potential for 
communications objects to become desynchronized due to transmission emjrs. Complete-object 

25 ttansmissions can also be mtennixed with updated-components-only transmissions on a periodic 
basis to prevent dysynchronization errors. The type of update distributed can also be conu-olled 
on a per-recipient basis by the attributes oftherecipienfs object (120, FIG. 3). 

FIG. 1 1 illustrates the process performed by the provider program 12 in distributing an 
entire object. The provider database 1 1 is queried (step 501) to determine all new or changed 

30 communications objects which need to be published, i.e., those which have a NewFlag attribute 
set to TRUE and a HoldFlag attribute set to FALSE. The program then loops (step 502) through 
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each communiGations object instance 100 which is to be published For each object the program 
reads the associated recipiwits 120 (step 503). The.prograifi begins a second loop (step 504) 
through each recipient 120. Using the recipient attributes and methods, a communications object 
instance is generated and transniitted to this recipiCTt (step 505, fiirther shown in FIG. 12). the 
5 loop is rq>eat6d for all recipients of the commimicatibns'o " ' 

At this point all new or changed communications objects have been distributed to their 
assigned recipients. However, a new or edited recipient may need to receive an existing 
communications object that has not changed. To account for this case the provider program 
queries the database for all recipients 120 vv*ose NewFlag attribute is TRUE and HoldFlag 
10 attribute is FALSE (step 51 1). The program then loops (step 512) through each of these 
recipients 120, quering for the associated communications objects 1 10 where the NewFlag 
attribute is FALSE (step 513). The program then loops (step 514) through each of these 
conununications objects 1 10 executing the object generation and transmission routine for each 
object (step 515). 

15 After all conununications object instances 1 1 0 have been transmitted, the program does 

anotfier query of the datobase for ail class instances ^ere the NewFlag attribute is TRUE and 
HoldFlag is FALSE (step 521 ). The program loops through these instances and resets their 
NewFlag attribute reset to FALSE (steps 522, 523). This prepares the database for the next 
round of editing and publishing. 

20 The procedures for generating and transmitting the communications object instance for 

each recipient are illustrated in the flow chart of FIG. 1 2. The program begms by creating (Step 
531) a header portion of an object markup file froin the attributes of the conmiunications object 
(110, FIG. 3). A header portion includes a header tag, the provider's system ID (the SystemID 
atuibute of database 100, FIG, 3), and any group IDs or category IDs (250, 251, 252, FIG. 6), 

25 the communications object 1 1 0 system ID attribute, and other attributes of the communicauons 
object appropriate for transmission. (Note that the combination of the providei's system ID and 
the comihunications object 1 10 system ID consitutes the communications object's UID described 
previously.) Next, the program reads all type definitions (144, FIG. 3) associated with the object 
(step 532) and writes them in the markup language format to the markup file (step 533). 

30 The program then retreives the communications object's methods and rules (step 534) 

M^ich are associated with the recipient (1 20, FIG. 3). Associating methods and rules with 
recipients allows each communications object instance to use optimal methods and rules for that 
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recipien;, An exan^>le is update methods. A communications object transmitted to a distribution 
server 32 such as a wieb server would use an Mpdate method for pull dis&ibution. A 
ponununications object transnoitted via e-mail to a consumer would use an update method for e- 
mailpudi disttibution. Receipt methods are anodier type of method that might typically vary by 
5 recipient. Next^ the methods arid lules that are associated directly orindirectly with the 
conununications object are read and written in the markup language to the markup file (steps 
536, 537)., , Indirect associations are methods or rules that are associated wth a page, element, or 
type defuiitiQn which is associated with the communications object This process is repeated for 
elements (steps 538, 541) and pages (steps 542, 543). Finally tiie necessary footer information is 
10 read from the communications object and written in tiie markup language to the markup file (step 
544). The markup file now includes the complete object ready for U-ansmission. 

If only changed components of the communications object were to be transmitted, rather 
tiian an entire object being resent, only tiie type definitions, elements, pages, methods, and rules 
which have changed, i.e., those having NewFlag attributes set to TRUE, would be stored in the 
15 markup file. Unchanged pages and elements would be omitted. 

Because the actual transmission may include addtional data besides the communications 
object itself, the following two steps involve executing any queries indicated by query elements 
(step 545) and reading any attachments specified by attachment elements (step 546). These two 
processes will be further desaibed m the discussion of data exchange control below. 
20 At tills point all the parts of the message are ready to be encoded for transmission. 

Encoding attributes and metfiods are associated witii the recipient 120. This allows 
communications object transmissions to be encoded in an optimal or desired format for each 
recipient. For example, e-mail recipients who use MIME attachments can receive MIME 
objects, while e-mail recipients who cannot read MIME can receive BinHex attachments or have 
25 . the communications object maricup file encoded directiy in the ASCII text of tiie e-mail message. 
Compression, encryption, and otiier encoding metiiods can also be applied. Encoding service 
objects may also be employed. Encoding control and encoding service objects are fiirther 
described below. The recipients encoding attributes and methods are read (step 547) and the 
encoding methods are executed (step 548). 
30 After encoding, the communications object is transmitted to the recipient according to the 

attributes and methods of the recipient (steps 550-551), As discussed previously, according to a 
preferred embodiment, objects sent directly to consumer computers 2 using the push method are 
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sent as e-mail messages or message attachments to the addresses of the' recipients:^ These ' 
transmissions can be queued using scheduled events 1 1 7 to reduce system load. Objects sent to a 
distribution server 32 for distribution using a puU method are saved to the appropriate web server 
document directory. Alternatively, based upoii the access the provider has to fh^ provider's web 

5 server, the object could be mailed to the Web sdver-adihihistrator, uploaded as ah HTTP form to 
the Web server, or otherwise stored for later piosting by the Web server adiiiinistrator. The 
transmission steps could also include an e-mail message, voicemail message, or other 
notification to the administrator tliat the object is ready to be stored on the server. Alternatively, 
transmission to a distribution server 32 can be automated through the use of a distribution service 

10 object. Distribution service objects will be further discussed be^ 

The final set of steps is to record data about the distribution in an acknowledgment 
association (121, FIG 3). Fir^ in step 552 an AckPrefererice value and the Acklnterval value are 
retrieved from both the communications object intance (1 10, FIG. 3) and the recipient instance 
(120, FIG. 3). This is necessary because acknowledginent can be controlled at the . 

IS commimications object level, or the recipient level. The acknowledgment attributes for the 
communications-object are transmittedias parameters.to a receipt method,:as further described . 
below.: The distribute form (336;:FIG: 9) contains radio buttons for three choices: no 
acknowledgmeiit;acknowledgment'iising:corximiuiications:object.setti 

using recipient settings. If the provider's choice was no acknowledgment (step 553), the routine 
20 is finished. If the recipient settings were selected (step 554), an acknowledgment association 
(121, FIG 3) is.created between the recipient (120, FIG. 3) and the communications object (1 10, 
FIG. 3). The AckDateTime value of the acknowledgment association (121, FIG 3) is set to the 
date/time of transmission plus the recipient's Acklnterval and the AckFlag is set to FALSE (step 
555). If the . communications object settings were used, the AckDateTime is set to the date/time 
25 of transmission plus the communications object's Acklnterval and the AckFlag is set to FALSE 
(step 562). The AckDateTime value and the AckFlag value of the acknowledgiiient association 
(121, FIG 3) can now be used by the provider program 12 to check for missing acknowledgments 
as of the acknowledgment due date as further described below. This completes the object 
generation and transmission routine. 

30 Consumer Program Operation 

. . . One advantage of the communications system of the present invention is that the 
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traxismitu?d.(»i»munications object instancex^ be automatically received, processed, stored, 
and indexed by the consumer program 22. Since the data is structured as an object and stored in 
an object-oriented databa^ 21, the data it contains can be easily searched using the consumer 
program 2? Jn prder. tp. Ipcate specific information or perfqrm certain functions. 
5 The consumer program 22 may Also coordinate with operation of o4er applications on 

^ the comumer computer 2 in order to provide the data to those additional For 
, example, name and address information may be transferred to a personal information 
management program. E-mail address information can be transferred to an e-maii program for 
its address book. Similarly, data can be transfeired to word processing or spreadsheet programs 
10 . to be incorporated into documents. Also, the proper information can be used for standard 
electronic data interchange (EDI) formats or other types of electronic information exchange. 
Alternatively and in most cases preferably, these other qjplications can access the consumer 
program through an API to retrieve communications-related data when needed. These 
applications can also call the methods of the communications objects to automate data 
15 interchange with the provider of the object This has the advantage of storing the data and 

methods only once on the coiisumer's desktop, saving stor^e space, decreasing complexity, and 
increasing the accuracy of the resulting communications. The use of an API for communications 
object access will be further discussed below. 

FIG. 13 illustrates the relationships between various screens and forms produced and 
20 used by the consumer program in processing objects stored in the consumer database. The 
consumer program is primarily reading, editing, and reporting on objects to the consumer 
database. Therefore, the menus and forms used by the consumer program are similar to a the 
brovvsingi editing, or reporting modes of any conventional database applic^^^^ Upon startup, 
an HTML page of the main menu 600 screen is generated and displayed. As with the provider 
25 : program 12, the menus and forms discussed with respect to the consumer program 22 are merely 
- illustrative of the capabilities of the system. They can be organized in any order or hierarchj . 
and other functions and features can be added by creating or modifying other menus, forms, or 
toolbars. 

The main menu 600 lists the principal types of functions which can be performed by the 
30 consumer program 22. The object list form 610 provides a directory to the communications 
objects in the consumer database. A name or other identifying information for each object is 
displayed in a list format. The name or identifying information also functions as a hyperiink to 
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amount and order of iiiforinatioh identifying the object, and organization of the communications 
objects in the list, using the preferences form 650. the choices lii' the object list form provide 
access to fomis for performing functions with respect to the attributes or methods of one or more 

5 communications objects selected in the object list 

The search foitn 620, as illiistrated in FIG. 1 4 will be used as ah example for processing 
of a form request The search forria 620 presents the user with a screen which allows the input of 
information, whether typed in or selected as check boxes. As illustrated in FIG. 1 4 the search 
form 620 includes a location to enter a search string. The search may also be expanded or 

10 limited based upon the fdiirh from which the search fonn iras reqiiiested: For example, if the 
search form 220 was selected froixi the selected object form 211, then only that selected object is 
searched. The user may elect to search all objects instiead by checking an apprcphate checkbox. 
. Similarly, the search can be limited to certain folders of coihmtmications objects. The user can 
also select the method for display of the search results. When the search form 220 is submitted 

15 as a request, the consumer program 22 will then act to process Ae form (step 57 in FIG. 2). The 
processingrof a search form rcsults^in a qu^ of the'constmier'database'21 according"to:the 
search attributes entered in the form; The query is performed in the same manner as queries for 
any object-oriented or .relational database.- A search report- isthehiigenerated'as thenextscreen . .r 
(step 53 in:FIG. 2), which is outputted to the browser program 50 and displayed (step 54 in FIG. 

20 2). In the search report, the consumer program 22 will automatically generate a hyperlink URL 
for each communications object name and page name displayed so that the respective object and 
page can be selected. 

• Referring back to FIG. 13, other functions shown in the object list form 610 (sort, export 
and print) operate as forms in a manner similar to that for the search form 620. Selection of the 
25 choice causes a URL request for the appropriate form, which is displayed. The user can then 
complete the information in the form and submit the form for processing. After processing, the 
. next appropriate screen will be generated and displayed. 

The sort form 634 presents a set of options for displaying communications objects, pages, 
and elements. Choices include sorting by container (such as a folder), order (ascending or 
30 descending), and unit (object,^page, element): The class instances in the consumer database 21 
are then sorted according to the selected criteria and redisplayed. ' 

The export form 645 operates to transfer data from the database to be used by other 
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applications, such a contact file, for a personal infonnation manager or a mail merge list for a 
word processor. First, a search or sort is perfonned lo select a group of comniunications objects, 
page^, or elements to be exported. The export form includes choices to select the elements to 
export, the destin^«ipn (such as a disk, file, clipboard, etc,) and a format. Upon submission of the 
5 completed form, the data meeting the export form critena is transferred to the selected 

destination in the selected format The data can then be. used by the other application. A screen 
identifying the results of the export is then displayed. 

The print fom 646 is used to print information in the database. Some routine print 
functions can be perfomied by the browser program 50. However, other printing functions, such 
10 as printing selected elements or pages or using special print formatting, can be perform^^ 
directly from the print form. The print form requests inforaiation relating to the selection of 
elements to be printed and the format for printing. A results screen can also be displayed after 
the print operation. 

The select object function results in a display of the selected object form 61 1 . An object 

15 may typically be selected by selecting its name on a form, which is hyperimked to the object. In 

the selected object form 61 U the names of the pages of the object are displayed in a list, with % 
hyperlmks to each page. From Ae selected object form 61 1, the user can sort, search, export and 
print using the forms as discussed above with respect to the object list form 6 1 0. Other choices 
are also possible with req)ect to the selected object which will be discussed further below, 

20 An edit object form 622 can be used to edit a communications object's attributes, 

including its component elements. Most attributes and elements of a communications object are 
defined by the provider and are not editable by the consumer. However, certain elements are 
defined by the provider specifically for editing by the consumer. These preference elements may 
include polling refi-esh intervals, return receipts, subscription elements, and notification 

25 elements. A consumer may also assign other attributes and associations to a communications, 
object These include folder assignments, nicknames, notes, notification priority, expiration date, 
and archive method. All communications object attributes and element attributes edited by the 
consumer are stored separately from the object in the consumer database 21 . This is 
accomplished by use of the CommObjeclPrefs class 1 27 and ElementPrefs class 1 47 shown in 

30 FIG. 3. Whenever the consumer first edits or adds conununications object attributes, an instance 
of the communications object preferences class 127 is created in the consumer database 21 and 
associated with the conununications object 1 10. Similarly, whenever the consumer fu-si edits a 
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preference elemoit; an instance of the elemioit pref^rencesda^ 147 is created and associated * 
with the elemiem 143. The edited or aksigiied attributes are stored iii these two class instances, 
and appropriate methods 141 aire stored widi or associated with these classes (these associations 
are not shown in FIG. 3 due to space limitations). In this way the consumer's data is not 

5 overwritten when an updated conununicatioQS object is received. Additioiially^ the consiuner 
may forward a communications object without including the consiittier's own attribute 
preferences, although the consumer may optionally choose to do so. Communications object 
forwarding is described further below. 

The delete object form 623 shown in FIG. 13 allows a communications object to be 

10 removed from die consuiher database 21 if the information is no longer deisired. The form also 
allows the constmier to reconfimi that the selected object is to be deleted. Additionally, the user 
may select certain options for deletion. Such options may include mmntaining the object for a 
predefined period before actual deletion, or storing basic information (such as an object name, 
UID, and update method) so that the object could easily be retrieved again if needed. 

15 The select page option displays the selected page form 612 which provides a listii^ of the 

elements on that page. :Typically;the page (142, FIG. 3) would be displayed.using the display 
order attribute of each page reference (146; FIG. 3) as specified by the provider. However, the 
user ixmyiesoTt the elements'iising.the sort'fonn 634^ If a page contains.editableipreference 
elements (143, FIG. 3), the HTML rendering of the element on the page would include the input 

20 form fields necessary to edit the preference element. It would also include the form processing 
method name necessary for the consumer program 22 to validate and store the edited element 
preferences in an element preference instance (147, FIG. 3). The export form 645 and print, 
form 646 can also be used with respect to a selected page or elements on the selected page. 

The notification report form 630 is selected from the main menu 600 in order to provide 

25 information about new communications objects, updates to existing objects, messages received 
by objects^ database status messages, and other news of which the user wishes to be informed. 
The notification report form provides the user with the capability to select and filler information 
received fix>m a provider. Operation of this form is discussed below in coruiection with 
notification element processing. 

30 The user can generate other reports relating to the consumer database uising the other 

reports form 640. Standard reports might include database statistics (total objects, pages arid 
elements; database file size; aiid suce of objects being held), object statistics (frequency of use; 
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last us^; age in $y$te;m; total age; size; number of updates; and last update), and transaction logs 
(number of iqxlates; percentage of CPU time used« online time used; percentage of errors; and 
types of errors). Additionally, consumers could specify their own database reports to be added to 
this form. 

The p^ferences form 650 allows the user to edit operatioiud preferences that apply to the 
consumer database 21 or consumer program 22 as a whole. These can include configuration 
options such as the initial menu to display upon startup, the colors and fonts for the forins and 
data, and field defaults. The user may also select options such as a default refresh interval to use 
for new objects, a default expiration period, and default settings for editing or preference forms. 

. Basic Communications Object Recept ion Process 

FIG. 15 is a flow chart illustrating the operations for processing communications object 
instances 1 1 0 received by the consumer program 22. As shown, an entire object is provided 
(Step 700) to the consumer program 22 each time any changes are made to the object. 
Alternatively, only the changed portions of the updated object may be sent in an object update. 
These processing steps for this case are not described but are substantially similar. Upon receipt 
of the object, the consumer program 22 first detranines whether the received object is a message 
object (step 701). Message objects and their processing will be explained below. If the received 
object is not a message object, the next step is determining whether the communications object 
abeady exists in the consumer database 21. This is done by querying (step 702) the consumer 
database 21 for the UID of the commimications object 1 10. If the UID does not exist the object 
is processed as a new object. 

For new objects, the consumer program 22 first executes the consumer's GlobalPrefs 
NewObjectReceipt method (step 703). This method allows the consumer to control the 
processing of new communications objects. Typically this method will store the object to the 
consumer database 21. However, the consumer may wish to discard objects received from any 
provider system ID on a list maintained in the consumer database 21, conunonly referred to as a 
"kill file". Additionally, the NewObjectReceipt method controls the permissions the consumer 
extends to the new object to execute its own receipt method(s). For example, new objects from 
providers whose system ID is not in the consumer database 21 may not be allowed to execute 
their receipt method, while new objects from known providers may be extended this privilege. 
Receipt methods trigger automatic actions taken \^en a conununications object or object update 
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- isfirstxtce]ved bya consuindrpm^^22?'.I^^^ 

i 

return an acknowledgment message back to tbe provider confirming the consumer's receipt'of the 
object or object i^xlate. Receipt nielhdds and acknowledgment messages are further described 
below. 

5 Once the NewObjectReceiptmethod has been execmed, the consimiers no 

preferences for new objects are retrieved (step 704) from the NewObjectNdtify attribute of the 
GlobalPre^ class (1 03, FIG. 3) in the consumer database 21 . A test is done to see if notification 
is desired (step 70S). If so the consumer program 22 retrieves and executes the consumer's 
GlobalPrefs NewObjectNdtify method (step 706), The user may wish to have the object 

10 displayed immediately, to receive an e-mail about the new object, to include a message about the 
new object in the user's notification report (includmg its size, methods, update intervals, etc), or 
any other notification action or combination of actions. Notification preferences and methods are 
fiirther described below. Also, different actions may be taken based upon the program state and 
operation involved with the object's arrival. For example, the user may viish to have an object 

15 displayed immediately if the user mantially selected it as a HTTP request fiiom a Web sit^, but 
not if tt.was anvobject update:retrieved.automaficaliy>via aAVeb.HTT^ 

consumer prograro'22, or if it.arrived via e-mail. Different actions may also be taken based upon 
attributes ormethods.of the communications object itself, or a comparison between these and. 
with the existing objects in* the. consumer database 21 . For instance; the consumer may wish to 
20 immediately display new objects fix>m selected providers whose system ID is already present, but 
only have notification in the notification report of new objects from any other provider system 
ID. 

' After any notification methods have been executed, the consumer program 22 executes 

any other system methods that may apply to new communications objects (step 708). For 
25 example, a Register method would check to see if the updated object wished to register a new 

public method (141, FIG. 3) in the consimier database 21. After any system methods are 

executed, new communications object processing is complete. 

In step 702, if an object already exists in the database, then it is processed to detennine 

what changes have occurred and what actions should be taken by the consumer program 22 
30 because of those changes. In this way the communications control system of the present 

invention functions not just as an information transfer system but as an event processing system. 

Both the provider and consuiher share control over the procesising that takes place when 
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kno\yIedge of ai event is transfened from provider to. consumer. The first event, the arrival of a 
communications object iqjdate, is processed in step 714. The version value of the updated 
communications object 1 10 is compared with the version value of the most recent versioh stored 
in the consumer database 21 . In the authoring process, the update association rule and method ( 
5 no, lOB) has ensuii^th^ any change to.a componenl of a communications obj^^^ 

conraiunications.object's version vduebemgincremrated. Therefore if tfie newly received 
. object's version value is older or equal to that of the existing object, the newly received object is 
not new. In this case the object is either discarded, or other processing may take place depending 
on the consumer's preferences, such as notification in the consumer's notification report (step 
10 713). Communications objects witii equal or lesser version values typically represent 
, retransmissions due to distribution errors by tiie provider, forwarded objects from other 
^. consumers, or manual retrievals of an object by the consumer when the consumer is unsure of the 
object's update status. 

If the newly received conununications object's version value is newer than thfc last 
15 version stored, the consumer program 22 first stores the updated object in the consumer database 
21 (step 715). The next set of steps involves updating communicatioiis object associations. When 
a consumer is able to edit data related to a communications object, tiiis data needs to be stored 
separately from tiie communications object so it is not overwritten by-a subsequent 
communications object update. The data structures necessary to accomplish tiiis are shovm in 

20 no. 3. First, when a consumer first edits any attribute relating to a coimnunications object 1 10 
as a whole, an instance of tiw communications object preference class 127 is created by tiie 
consumer program 22. This instance 127 has a one-to-one association witit its parent 
communications object 1 10. It also has a one-to-many association witii folder instances 115. 
These associations are created using tiie edit object form (622, FIG. 13), and allow tiie consumer 

25 to furtiier control processing related to tius communications object. A consumer is also aWe to 
edit preferences related to specific elements 143 witiiin tiie communications object 1 1 0. As 
described above, tiiese preference elements are a mechanism for providers to give consumers 
control of specific types of communications object update processing. Whenever a consumer 
edits a editable preference elemem 143, an instance of tiie elemem preference class 147 is created 

30 by tiie consumer program 22. This element preference instance 1 47,has a one-to-one association 
witii its parent element 143. Optionally it may also have an association witii one or more folder 
instances 1 15, which allow the consumer to fiirtiier conuxil processing related to tius preference 
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element. When an upkiated communications object is receiVed by the consumer prograin 22, the 
associations between the conununications object preference instance 127 and each element 
preference instance 1 47 need to be iqxlated to the hew "parent" communications object 1 1 0'and 
elements 143. These update steps are shown as.steps 716 and 717 of FIG. IS. Referring again to 
S FIG. 3, if an element 143 for ^iiich an association with an element preference 147 exists is' 
absent in the communications object update, the consumer may wish to be notified and/or the 
element preference instance 147 deleted. This can be accomplished via a notification method as 
described below. 

The consumer program 22 then proceeds with additional processing steps depending on 
10 the contents of the new and old versions of the communications object 1 1 0. First, this means 
executing any receipt methods 141 or rules 140 associated with the communications object 1 10. 
Referring again to FIG. 1 5, receipt methods 14 1 or rules 140 assigned by the provider are 
executed first (step 721). Reiceipt methods 141 or rules 140 assigned by the consumer, i.e., tiiose 
associated with the conununications object preference instance (1 27, FIG. 3) associated with the 
IS communications object, are executed n^t (step 722). Receipt methods and rules and their use are 
further described below. 

After receipt method processing, notification processing is carried out. Processing of 
notification elements (steps 723 - 727) is further described.below. After notification processings 
the consimier program 22 executes any other system methods that apply to updated 

20 communications objects, such as the Register method (step 73 1 ). Finally, the constmier program 
22 checks the archive preference attribute of the conununications object preference instance 
( 127, FIG. 3) to see if it exists (step 735). Archive preferences determine the number of 
previous instances of a commimications object stored in the consumer database 21 . This is 
identical to how archiving works for previous versions of communications object components 

25 stored in the provider database 11. In a preferred embodiment, consumers can control archiving 
either globally or by individual communications object. If the consumer has indicated an archive 
prefereilce for the object, the consumer program 22 executes the archive method indicated by the 
. communications object preference (step 736). If no such archive preference exists, the consumer 
program 22 executes the archive method indicated by the consiuner*s global preferences (103, 

30 FIG. 3) in step 737. This completes die processing of an updated commimications object 

Combined P rovider and Co nsumer Program Operation . 
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The functipns of provider and consumer programs and databases have been separated in 
the above disfc^ussion in. order to simpliiy the description of the commimications system of the 
preset invention. HQAyeyer;^ in one embodiment, th^ program functions and databases are 
combined. Thus* a single databs^ includes all of the commiMiucations objects and object 
5 components which have been created or received by the user. This eliminates complexity and 
,saves disk space for the user, the program offers the provider fimctions when creating and 
distributing commimications objects, and the consumer functions when receiving and processing 
them. Combining the program functions and databases in this way yields significant additipnal 
functionality not available when the programs and databases are separate. 

10 First, conununications relationships can be linked in both directions between users. 

Referring to FIG. 3, when the programs are separate, the provider must create and maintain a 
recipient instance 120 for each desired recipient. When the programs are combined, however, the 
functions of a recipient instance 120 can be replaced by a commimications object instance 1 10 
received from that recipient By including an element 143 of a special composite type 

15 "ReceiveObject", the received communications object 1 1 0 can supply all the fields required of a 
recipient instance 1 20, including network address, prefenred encoding fonnat, and preferred 
transmission method. The provider only needs to make an association once between the 
recipient's communications object and the provider's own communications object or objects 1 10. 
From that point onward, the provider no longer needs to maintain these attributes or methods of 

20 the recipient instance 120, as they will be updated automatically fi-om the recipient's 
communications object 110. 

Second, all the elements, type definitions, and methods of both received and transmitted 
objects are present in a single database and program operation environment. This allows the 
provider to use the attributes and methods of received objects for other purposes. For example, 

25 special communications object types can be used to supply services needed by other 

communications objects. Such services include directory services, authentication services, 
payment services, and feedback services. These "service objects" will be further discussed 
below. Components fi-om received communications objects can also be reused within .the 
provider's own communications objects, thus creating "synthesized objects". Synthesized objects 

30 will be further discussed below. 

Third, the elements and methods of the provider's own communications objects can be 
made available to communications objects from other providers. This allows for the automated. 



BNSOOCID: <WO_©732251A1_l.> 



wo 97/32251 PCiyUS97/03205 . 

- -56- 

. intelligent exchange, of many types of standard pexsqnal of bu^iness data i^cU otherwise would 
. require human efFort Data exchange autdniation will be further discussed below. 

Fourth^ a single notification report system can be used to report messages and events to 
the user, whether they are associated with provider objects or consumer objects. Notification 
5 reports are described below. . . .... 

Evgtit Lwps, Evgnt Logging, mi Evgnt Sghgdwling 

The provider program 1 2 and consumer program 22, whether combined or separate, 
operate internal event processing loops similar to many computer operating systems or software 
programs which need to handle us^ and system events as well as scheduled or automatic 

10 operations. The main event i(>op is illustrated in FIG. 1 6A. In this loop the program first checks 
to see if there is a system event waiting for processing (stq> 751). If so, the program processes 
the event (step 752). It then determines if the event requires logging (step 753), either by a 
method included directly in the event, or by checking the system ID of the source class initiating 
the event against event log^ng rules in the rules class 140. If logging is required, the program 

15 generates^anf instancerof theiogged event class (1.1 8, FIG: 3)» recording .the date and time of the 
event, the system ID of the source object requesting the evoit, the system ID of the target object 
carrying out the:event;'the event type (for example; polling; insertingv editings deleting), and the 
event results. 

If there is not an event waiting in step 751, or when an event does not require logging in 
20 step 753, or when the event logging task is finished in step 754, the program begins idle 

processing tasks (step 755). During idle processing periods other specialized event loops can be 
processed tmtil the expiration of the main event loop (step 756). These specialized event loops 
may include a scheduled event loop, an inbox/outbox monitoring loop, a rule-monitoring loop, 
and so on. The specific event loops used are not a limiting feature of the invention. 
25 The scheduled event loop is shown in FIG. 1 6B. Whenever an event needs to be 

scheduled by any method, system procedure, or direct user input, it generates an instance of the 
scheduled event class (117, FIG. 3). This instance includes the daie and time of the event, the 
syistem ID of the object requesting the event, the system ID of the object carrying out the event, 
the event type, and the event parameters (if any). When executing the scheduled event loop, the 
30 provider program 1 2 or consumer program 22 first rietrieves the earliest scheduled event instance 
(step 761). It then checks to see if the scheduled date/time is equal to or less than the current 
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date/time (step 762), If so, it processes the event (sjep 763), then tests to see if .event logging is 
required (step 764), as described above. If eyei^t iQgging is required, it generates and saves an 
instance of logged eyent class (1 18, Fiq,.3> in step 765. Finally, it either deletes or updates the 
scheduled event instmce (step 76$), depending on. the nature of the event A communications 
5 object update polling event would, for example, be incremented by the next polling interval. 

At the end of this process, or if the earliest scheduled event instance had not yet elapsed 
in step 76 1 , or if an executed event did not require logging in step 764, the program tenninates 
the scheduled event loop (step 767) and conunences the next idle processing task. 

ADVANCKD COMMI rMinATI ON ORJFrT TVPRS 

10 The basic architecture of a communications object system lends itself to many specialized 

^ communications object types which enable significant additional fimctionality. As discussed 
earlier, in a preferred embodiment each of these specialized types are implemented as subclasses 
of the contounications object superclass 1 10. Examples of these subclasses are Ulustrated in 
na 17. These examples are merely illustrated of the users of communications object types and 

IS not a limiting feature of the invention. 

Alternatively, these ^ial object types could be distingiushed by the use of a special 
element contained in a communications object. This element would have a special composite 
type such as CommObjectType, and the value of this element would deteimine the 
communications object object type for purposes of processing by the consumer program 22, 
20 provider program 1 2, distribution server 32. or a communications object system partner server 
1302. 

JMessage Ohjftr.tS 

CommunicaUons objects represent a transfer of communications intelligence, in the form 
of data, metadata, and instructions, firom a provider to a consumer who wishes to form a 
25 communications relationship with that provider. Once the communications object has been 
exchanged, fimher communications between the provider and consumw can cany greater 
intelligence because they can be be orginated and received as transmissions between these two 
jcommunications objects. Although these messages can be structured in any form, in a piefened 
enibodiment they are simply a special communications object type called a message object 1 10. 
30 This means they can be generated, encoded, ttansmitted, received, and processed in the same 
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fe^on as any dflieir coiibiimiiciEttidns bbjedt; iTie oiily diffi*ehcc is that the generation or receipt 
of a niessage object may not result in an update to the sending or receiving communications 
object, biit rather the execution of one or more methods at the sending or receiving program, and 
optionally chaiiges to other objects or object ciirapohents in the sending or receiving databases. A 
5 communications object update may be considered a special fonn of niessage object which 
includes changes to the receiving commuiiicatioiis object. 

Message objects can also be sent to or received froni any other conununicatibr\s server, 
program, or process which is not a formal psut* of the system but is compatible with the message 
object format Not all messages produced by a communications object system need take the form 
10 of message objects, however. The attributes and methods of corhmunications objects can also be 
used to generate and receive other structured or unstructured message fomiats compatible with 
other communications systems, servers, or processes, or any custom format of the provider's 
choosing. 

As with any communications objects 1 1 0, message objects may be transmitted or 
15 received via eidier the push or pull technique, using any conununications protocol. Specifically, 
message objects can be transmitted and received using both store^and-forward protocols, such as 
SMTP ermail, and direct transmission protocols, such as HTTP. In the latter case, message 
objects can take the place of HTTP forms for automated processing by the web server, such as 
Common Gateway Interface (CGI) script processing. 
20 The processing steps for receipt of a message object by the consumer program 22 are 

illustrated in FIG. 1 5. First, a newly received object is tested to determine if it belongs to the 
message object subclass (step 701). If so, the next test is to see if the message object's "parent" 
exists in the consimier database 21 (step 71 1) by searching for its UID. The parent is the 
communications object (1 10, FIG. 3) that produced the message object. If the UID of the parent 
25 object is not present, the message object is rejected as invalid. This may also resiih in an error 
message being displayed'to the user or placed in the the user's notification report, depending on 
the user's preferences. 

If the pirent UID exists, the final step is to execute the message object's receipt method or 
methods. Since a message object is simply a special type of communications object it may cany 
30 its own methods, or it may call the methods of its communications object "parent". Additionally, 
when received by the originating provider program 12, it may call any other method 141 present 
in the provider database 1 1 which originated the parent communications object For example, a 
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conimunications object coulij incJude a receipt method 141 named GetStatData which obtains 
statistical data from a consumer database. 21 and returns a message object to the provider 
program 12. When the message object is received by the provider program. 12^ it may execute a 
receipt method 141 named PostStatData which is present in the provider database 1 1 ; but not in 
5 the original communications object 1 10. Altematiyely, method names can be polymorphic. In 
this case a method included in the conrniiiriications object 1 10 could perform one action when 
received by the consumer program 22, but another action when called by a message object in the 
provider program 12. The method can distinguish between these programs by matching the 
system ID of its originating database (100, FIG. 3) with the system ID of the database in which it 

10 is executing. (Such a match may also be made on a group lU rather than a specific system ID.) 
For example, a communications object 1 1 0 could include a method TransferStatData vyrhich, 
when executed by the consumer program 22, would be used to gather statistical data from the 
consumer database 2 1 and return a message object to the provider. However, when the same 
TransferStatData method is executed by the message object back at the provider program 12, the 

15 method could be used to post the statistical data to the provider database 1 1 (or another database 
maintained by the provider). 

Because of this, message objects generally do not need to transport their own methods, 
but can instead call methods present in thek parent communications object (aheady stored in the 
consumer database 21 and provider database 1 1), or other methods from their originating 

20 provider database 1 1 . This makes them a highly efficient means of transporting strucnired 
message data and initiating automated processmg of that data. 

For providers, message objects allow the provider program 12 to operate similarly to a 
consumer program 22. In other words, message objects returned to a provider program 12 by 
communications objects which originated in that provider program 12 can execute the receipt 

25 methods, notification methods, and other processing methods of their parent communications 
object 1 10. This gives the provider many of the same benefits that the communications object 
gives to the consumer. The ability for both the provider and consumer to benefit equally from the 
automated processing of message objects is a core advantage of a communications object system. 

Component and Cnmpftgjte Ohjects 

30 Another powerful feature of communications objects is thefr ability to be physically or 

logically nested. This nesting is illustrated in FIG. 3 by the one-to-many association 1 lOA for 
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commiihicatibns objects 1 10. CbmniUTiicatioiis bbjeds coiitMg^ by another communications 
object are called compbmit tibjects, and the container object is called a composite object FIG. 
17 illustrates the ohe-to-mahy relationship between the composite object subclass 8 1 1 and the 
component object subclass 812; 

5 Each c6mi)oheitt obj^t has ah assdciation 1 1 OA to the composite object which contains 

it A component object may be contained by more than one composite object. As with other 
associatibhs in the provider databaise 1 1 , changes to component objects can be propagated 
upward to the composite objects wfaidi contain them via the update association method (FIG. 
lOB). Thus, for editing asid display purposes, coniponent objects can be treated as one or more 

10 meithods, rules, pages, eletii^ts, or type definitions that become part of the larger composite 
cointetmiclitions object Composite, objects can access the elements or methods of their 
c(»r^onent objects in the consumer database 21 just as if the elements or methods were 
contained directly in the composite object In this manner component objects can be dealt with as 
independently transferrable objects for purposes of updating, distribution control, and other uses 

IS as described below, while still functioning as an integral part of the composite objects which 
contain them. 

Composite objects may optionally contain additional elements 1 43 representing their, 
component object:members.:In this way a composite object can be separated from its component - 
objects yet still contain the information necessary to retrieve or update its component objects. 
20 This use of composite objects may be more fully understood in the description of distribution 
control functions below. 

Composite and component objects are particularly useful for creating many different 
kinds of metadata structures in communications object system databases 100. Example are 
directory category hierarchies and discussion response thread hierarchies, shown in FIGS. 29A 
25 and 29B . Another example is schedule objects 

Svntiiesized Objects 

When the functions of the provider program 12 and consumer program 22 and their 
respective databases 1 1 and 21 are combined, a provider can create synthesized objects. A 
synthesized object is a conununications object which contains conaponents or component objects 
30 from otiier providers. These are refened to as "external components" or "external component 
objects". FIG. 17 illustrates the synthesized object subclass 813. A synthesized object does not 
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necessarily require a special communications object type, although it may be desirable for 
licensing, authentication, or other purposes. The uses of synthesized communications objects 
may be more fully understood from the description of service object types below. 

Just as witii a standard communications object, when the external components or 
5 a)inpoiSbht bbjects of a synthesized Object change after the receipt of an updated object from the 
external provider, those chaiiges tngger the update association rule, described above. Thus the 
changes are propagated upward to the components and communications objects which contain 
them using the update association method (FIG. lOB). In this fashion synthesized 
communications objects transmit the chaiiges io their external components in the same fashion as 
10 they do with their internal comi)onents. 

Service objects are another special class of communications object whose primary 
function is to provide communications services to other conununications objects. As shown in 
FIG. 1 7, the service object siq)erclass 81 5 can be further broken into subtypes such as 
15 registratioii service objects 830, maintenance service objects 83 1 , name service objects 832, 
directory service objects 833, and so on. Service object types can be used by the provider 
program 12 and consumer program 22 to distinguish the services that service objects make 
publicly available to other objects. The use of service objects wUI be discussed in separate group 
of sections below. 

20 User Qb>ectq 

User objects are communications objects 110 used to represent communications object 
system users or groups of users in a coihmunicalions object system database 1 00. User objects 
are shown as class 816 of FIG. 17. User objects 110 have many different applications for both 
service object partner servers and multiuser implementations of a communications object system 
25 database 100. User objects will be further discussed in the service object and advanced system 
architecture sections below. 

Schedule Ohjftrt^ 

Schedule objects are conununications objects 1 10 used to represent scheduled real-worid 
events in a conununications object system database 1 00. Scheduled objects are shown as class 
30 817 of FIG. 17. Schedule objects 1 10 are used to coordinate conununications about events, such 
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as phone caJls bxiA meetiiigs. Schedule objects will be further disc\issed in the scheduling control 
section below. : • • ' 

rOMMI INir ATIONS CONTROL RJNCTIQNS 

The preceding sections have explained die basic mechanisms by which communications 
5 objects are created, updated, and distributed by a pro\dd^, and received, processed, and stored by 
a consumer. While fte transfer of a Qommunications object may itself conuhunicate infonnation 
between the provider and consumer, this is only a first use of the present invention. A second 
principal use is employing the transferred communications object to control and automate 
additional communications between the provider and consumer. The following sections will 
10 explain these control functions as they apply to distribution, encoding, transmission, reception 
and acknowledgment, notification, updating, data exchange, communications object exchange, 
forwarding and chaining, transfer, termination, event tracking, archiving, and reporting. Two 
additional types of control functions, for multinetwork communications and scheduling, will be 
discussed in the advanced system architecture sections. This set of control functions is not 
15. exhaustivebut merely: illustrative^of how,the control capabilities.of a coaununications.objectv . 
system maybe applied. 

Distribution Control 

A provider may wish to distribute different information to different consimiers. In 
addition, a provider may wish to grant different consumers different communications control and 

20 access privileges. One way to accomplish this is for the provider to create different 

communications objects and assign them (via push) or make them available (via pull) to different 
consimiers. However, v^Aien a large number of conununications object components are being 
distributed to large niunb^ of consumers, this solution quickly becomes unwieldy. A second 
drawback to this approach is that when a global naming system is used, each of these 

25 communications objects must have a luuque name. These different names. can easily confuse 
consumers, vAio would rather be able to associate a single conununications object name with the 
real-world name of the person, company, product, service, etc. that the conununications. object 
represents, thus, in a preferred embodiment, providers would be able to automatically distribute 
customized versions of the same conununications object. 

30 ^ In addition, in some cases it is preferable for the corisuxner to control this customiMtion 
process. For example, a provider may offer several versions of a softwa-e product, all sold under 
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the same naine. The. provider may wish to offer a single communications object corresponding to 
that product^ name, yet allow it to be customized for the paiticular product versions. However 
since the provider dpes not know which version each consumer is using, it is preferable for the 
consumer to control customization. 

5 This leads to four scenarios for distributipn control from a single provider to one or more 

consumers: provider control using the push technique, consumer control using the push 
technique, provider control using the pull technique, and consumer control using the pull 
technique. This section will discuss each of these in turn. Distribution control involving multiple 
providers will be discussed further in the multiuser operation section below. 

10 provider control using the push technique, we have already described hb 

can assign different communications objects to be distributed to different consumers usmg the 
create new recipient fonn or edit selected recipient form (311,3 12, FIG. 9). Distributing 
customized communications objects simply requires extending this same technique down to the 
component level. This means the components for each communications object instance are 

15 customized for each recipient during the communications object instance generation process. 
Hiis process is analogous to steps 534, 545, 547 of FIG. 12 where object methods, encoding 
methods, and transmission methods are customized for each recipient by associating them with 
the recipient instance (120, FIG, 3). 

Any communications object component can be used for customized distribution. FIG. 1 8 
20 illustrates the data structures necessary for controlling distribution using pages 142. While pages 
are the preferred embodiment that will be discussed here, other classes, such as elements 143, 
could also be used. Alternatively, additional contahier classes could be employed, such as page 
groups. The components or component groups used for distribution control are not a limitmg 
feature of the invention. When page distribution control is used, a rule 140 exists such that the 
25 creation of any page instance 1 42 also creates an instance of a page subscription element 853 
(and deletion of the page instance also deletes the page subscription element instance). A page 
subscription 853 is an instance of element class 143 with a composite type PageSubscription. 
This composite type includes a logical value SubscribeFlag. The rule 1 40 that creates a page 
subscription instance 853 also creates a one-to-one association 855 with the page 142 it 
\0 represents. Therefore, a list of page subscriptions 853 associated with each page 142 contained 
by a conununications object instance 1 10 can be displayed on the edit selected recipient forai 
(312, FIG. 9). The SubscribeFlag attribute ofeach page subscription 853 can be represented as a 
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checkbox on this fonn. By checkihg the desir&d boxes, the pravider can create an association 
856 between the recipient instance 120 and the page subscription 853. This results in specific 
pages being assigned to the communications object instance that will be transiriitted to the ' 
recipient. 

5 FIG. 1 9 illustrates the three minor modifications that selc^ive page distribution requires 

in the object generation md trahsmssio^^^ 12. First, instep 881, only 

those Qrpe definitions (144, FIG. 3) associated with elements (143, FIG. 3) contained by pt^es 
(142, FIG. 3) associated with page subscriptions (853, FIG.^ 18) having a SubscnbeFlag 
attribute which is TRUE are selected for inclusion in the object maricup file. Second, in step 882, 

10 only elements contained by pages associated with page subscriptions having a SubscribeFlag 
attribute which is TRUE are selected. Third, in step 883, only pages associated with page 
subscriptions having a SubscribeFlag attribute which is TRUE are selected. All other steps are 
identical to those shown in FIG. 12. 

' ■ The second casie covers how the provider can allow the consumer to control distribution 

15 using the push technique. For example, a software company might offer multiple pages within a 
communications object pertaining to a software product. Each page would correspond to a . 
particular, version of that product. If the company did not know which version a consumer was 
using^ it could include .a menu of these pages in. the communications object. A consumer's 
choices firom this menu would be automatically retumed to the provider via a message object, 

20 . which would invoke a method in the provider program 12 to change the consumer's page 
subscription settings in the provider database 11. in this way the consumer can choose to 
"subscribe" to the page or pages corresponding to the product version the consumer is using. 
This saves transmission time for the provider and file space for the consumer. 

To accomplish this requires first that the p^ge subscription elements 853 be transmitted 
25 with tiie communications object as a preference element that will be editable by the constimer. 
To inclttde page subscription elements in the communications object, an **Include Vagc 
Subscription" checkbox can be included next to the "Include Page" checkbox for each page listed 
on the create object or edit selected object form (321, 322, FIG. 9). As shown in FIG. 18, when 
the fomi is submitted with an "Include Page Subscription" checkbox selected, a contained-by 
30 association 857 is created between this page subscription elemeiit instance 853 and the selected 
communications object instance 1 10. In addition, when consumer page distribiition control is in 
effect, each page subscription instance 853 has an association 858 with a PageSubscribe method 
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8S4. Tliesetwo associations 857 and 858 mean that all page subscription elements 853 and one 
PageSubscribe method 854 will be; transmitted as communications object components in the 
same manner as any other communications object element or method. 

Once the communications object is received by the consumer program 22, the 
5 SubscribcFlag values of the page subscription elements 853 are editable by the consuiner- using 
the edit object fonn.(622, FIG. 13) (The operation of this form in conjunction with the operation 
of the consumer piogram 22 is described above.) When this fonh is submitted to the consumer 
program 22, its contents are processed by the associated PageSubiscribe methc^. This method 
first creates a message object instance (810, FIG. 17) containing the changed page subscription 

10 elraients 853 and the receipt method PageSubscribe. It then transmits this message object 

instance 810 back to the provider program 12. When the message object instance 810 is received 
by the provider program 12, the PageSubscribe receipt method is executed using the changed 
page subscription elements 853 as a parameter. As a polymorphic method, fiiis results in an 
HKlatc operation that changes the SubscribeFlag values of the page subscription elements 853 

15 associated with the recipient 120. This in turn removes the association 856. In this way the 
consumer is able to edit his/her own page subscription settings in the provider's database 1 1 . An 
updated communications object instance can be retumed by the provider program 1 2 
immediately, at a scheduled future date/time, or at the time of the provider's next publishing 
operation. 

20 Both the foregoing distribution control processes operate via the push technique. For high 

volume distribution, the pull technique is more likely to be employed. Distribution control usmg 
the pull technique is illustrated in FIG. 20, Pull distribution requires the consumer prdgram 22 to 
interact directly with a distribution server 32. In a preferred embodiment, this can be 
accomplished using a distribution service object 1310 and a distribution partner server 1302, 

25 These will be fiirth^r discussed in the distribution service object section below. Customized . 
distribution, whether controUed by the provider or the consumer, has two requirements. First, the 
components of a communications object must be available independently on the distribution 
server 32. Second, the instructions governing the selection of these components must execute 
either in the consumer program 22, or the distribution server 32, or both. In essence, program 

30 logic must be used to replace the human intelligence of the provider in determining how to 
customize communications object components. 

The first condition can be met by breaking die communications object into a composite 
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communications object 900 and a set of cdniptohent objects 901 . Two such component objects 
are shown in FIG. 20, however any iiinnber of component objects can be used/ the second 
condition can be met by either including a distribution control method in the composite 
communications object, or transferring a second conmiunications object with one or more 

5 distribution control methods to the\distnbution server 32, or both. Alternatively, the distribution 
control instructions can be programmed directly into the distribution server 32, or supplied via 
another program or object called by the distribution server 32. FIG. 20 illustrates an instance of a 
distribution control communications object 902 produced by the provider program 12 and 
transmitted to the distribution server 32. 

10 Provider control of distribution via the pull technique involves the following steps. First 

the object instance generation and transinissioii routine (FIG. 12) generates the composite 
communications object ixistance 900 (step 910) and the compoiient cpnimunications ob^ 
instances 901 (steps 91 1, 912). The composite communications object instance 900 includes a 
distribution control method 901 . This method can execute automaticaUy (as a receipt method) or 

15 manually (with.consumer acdvadon) wifliin the consumer program 22 to retreive die desired 
compbnent':objects;fiomitherdistribution:seiver':32; :If some distributioncontrol logic wiU reside 
at the distribution server 32, the object instance generation and transmission routine also needs to 
produce:x)ne or more distribution control objects 902 (step 913), or this logic must be 
alternatively supplied to the distribution server 32. (One alternate method of supplying this logic 

20 . is a distribution service object 1310. Distribution service objects will be further described 

below.) Each of these objects are then transmitted to the distribution server 32 (steps 920, 921 , 
922, 923), either separately or in a combined transmission. 

The next step is for the consumer to obtain a copy of the composite communications 
object instance 900 (step 930). When the object is received by the consumer program 22, the 

25 distribution control method 93 1 can be executed automatically as a receipt method or manually 
by the consumer (step 93 1 ). The cUstribution control method 93 1 determines >^ch component 
objects 901 should be retrieved. These instructions may incorporate any logic or business rules 
the provider wishes to employ; using whatever data is available to the communications object in 
the consumer database 21 or elsewhere in the consumer's computing environment. For example, 

30 if the communications object represented a software product, the distribution control method 93 1 
could examine the consumer database 21 or die consimier's locied or network environment to 
determine if the product was installed and what version die consunier was using. Alternatively it 
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could iiir^sent an mpnt fpnn to the. consumer tq gather other relevant data for pmcessing^vThe 
distribution pontroimethod 931 could then determine and download the appropriate component 
objects 901 from the di$tribjition server 32 (stisp 932). For example, it could download the 
component pbjects 901 that correspond to the version of the product the consumer was using. If 
5 the consumer did not have the product installed^ the distribution control method 93 1 could 
download the copippnent objects 901 that are comjMitible witfi the consumer's computer system. 
Alternately, the .distribution control method 93 1 could transmit data it retrieves from the 
consumer database 21 or the consumer's computer environment to the distribution control object 
902 on the disuibution server 32 (step 933). This data could then be processed by the distribution 
10 server 32 to determine the optimal component objects to return to the consumer program 22. This 
can be more efficient than transferring a sizable distribution control method tp each consumer. 
Automatic dato (exchange will be further discussed below. 

The final scenario is consumer control of distribution via the pull technique. This is 
similar to consumer control via the push technique, and again uses page subscription element 
15 instances (853, FIG. 1 8) and a PageSubscribe method (854, FIG. 1 8). However there are three 
differences. First, the page subscription elements include additional attributes which allow them 
to function as^ link elements to the corresponding component objects location on the distribution 
server 32. Link elements are more fiiUy described in the section on communications object 
exchange control below. Secondly, the PageSubscribe method operates differently, as explained 
20 below. Thirdly, both the page subscription element instances and the PageSubscribe method may 
be contained in either the composite communications object 900 or the distribution control object 
902. 

Once the composite conununications object is received at the consumer program 22, the 
consumer can control component distribution in one of two ways. If the page subscription 

25 element instances,(853 , FIG. 1 8) are included in the composite communications object, the 
consumer can edit their SubscribeFlag values using the edit object fomi (622, FIG. 1 3). When 
this fomi is submitted to the consumer program 22, the PageSubscribe method (854, FIG. 18) 
processes the fonp data. The PageSubscribe method then uses the link attiibutes of each page 
subscription element instance (853, FIG. 18) to reueive from the distribution server 32 the 

30 component objects .901 for whom SubscribeFlag equals TRUE. lif the page subscription element 
instances (853, FIG. 1 8) are included in the distribution control Object 902, the consumer could 
invoke a hyperiink in the edit object form (622, RG. 13) which calls an HTML form from the 
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distnbuUon server 32v This form displays the pa^e subscription element instances (853, FIG. 18) 
for editing in the same manner as tiie edit object foim (622, FIG. 1 3) displays in the consumer 
program 22. However, vAim this form is returned to the distribution server 32. the PageSubscribc 
mefliod in the distribution control object 902 or its eqmvaierit is iised to return the specified 
5 component objects 901 to the cdnsiimer program 22. Again, this latter process can be more 
effici^t than distributing page siibsimptioh elraieiits and large PageSubscribc methods in the 
composite commimicatibns object to all consumers. 

• Oiie advantage of iising composite conununications objects for distribution control is that 
a single composite communications object 900 can be used to control updating for multiple 
10 component commtmications objects. This will be ftnther explained in the discussion of update 
control, below. Alternatively; distribution control can be accon^lished using specialized forms 
of data exchange control. This vnll be further explained m the discussion of data exchange 
control, below. ^ 

Encoding Control 

15 Encoding, refers-to the forQiattiiig:of.conimimication5data.toJ^ 

value. Communications encoding may take many forms, including hunum languages, computer 
languages,.character sets,, data file formats,.compression. formats, .transmission formats,- . . 
encryption formats, and display fomiiats; Multiple types of encoding may be applied to tbe same 
communications transmission. A commtmications object system represents a significant 

20 improvement over existing communications encoding control processes for three reasons. First, 
conununications objects provide a simple, automated way for the communications sender to 
know which encoding formats are optimal for a communications recipient Secondly, because 
this encoding data is stored within a structured database 11, 21, it can be easily accessed by the 
provider program 12, consimier program 22, or another software program using an appropriate 

25 API, for the purposes of automating both the encoding process for the sender and the decoding 
process for the receiver. Thirdly, the sharing of encoding and decoding methods can be 
dramatically simplified through the use of encoding service objects. Encoding service objects 
will be further discussed below. 

Communications objects can control the encoding of transmissions of the 

30 conununications objects themselves, communications object updates, relied objects such as 
message objects, attachments to conununications object transmissions, or any other form of 
message, data stream, broadcast or data exchange process. They can also control both the 
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cncp^g process for the sender (be it the pipyider or consximer), and the decoding process for 
thereceiyer. 

The fundamental process by whidi communications objects control encoding arid 
decpdii^g is as follows. Using the provider program 12, the provider supplies within a 
5 po^ynunicatipns object (H FIG, 3) one or more elements, methods, rules, (143, 141 , 140. FIG, 
3) or any combination of these go vemmg the encoding formats to be used by communications 
transmissions resulting from this communications object Once the communications object 1 10 is 
acquired by a consumer, any communications transmissions resultiiig from the communications 
object, whether generated manually by the consumer using the consumer program 22, 
10 automatically by tiie consumer program 22 itself, or automatically by another software program 
accessing the communications object via an API, will use the appropriate encoding. When such 
transmissions are received back by the provider program 12, or by another software program or 
process which has been progranuned by the provider or by other communications objects 
received from the provider program 12, these transmissions can be decoded by reference to the 
15 same data and methods included in the original communications object 

Encoding can be applied directly by methods contained within the communications 
object, by encoding service objects, by system methods contained in the programs 12, 22, by 
other utility software programs called by these programs, or by other applications that call the 
data and methods of the communications object via ah appropriate API. 
20 Encoding conu-ol is particularly relevant to communications security. Many data 

encryption systems operate through the use of a digital key or signature for securely encoding a 
communications message, and a second related key for decoding and authenticating the message. 
The two keys are related through the use of a mathematical algorithm. Such systems are often 
referred to as public/private key encryption systems. The encoding key, which is generally 
25 publicly available, is called the public key; the decoding key, which is guarded by the recipient, 
is called the private key, Public keys can also be digitally "signed" so they can be authenticated 
via reference to a trusted source. The use of encryption algorithms, public and private keys, 
digital signatures, authentication, and other topics related to secure communications is discussed 
generally by Bruce Schneier, Applied Cryptography. Second Edition { 1 996), which is 
30 incoijjorated herein by reference. 

As with other forms of encoding, communications objects are an excellent mechanism for 
simplifying and automating public/private key encryption. Referring to the data suiicmres in 
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FIG. 3, this iis'becatise a GbmmiMcatibns'^^ 1 tO is an ideal vehicle for l^s^it^ng one or 
more of the provider's public keys to the consumer's computer, v^ere it can be used to 
automatically encrypt messages being returned to the provider. The public key can be stored as 
an element 143, and the decryption niethod can be stored as a method 141 . By encrypting the 

5 return mesisage as a message object 1 1 0, the message object can invoke a receipt method 1 41 at 
the provider progrEun 12 which can automatically decrypt the message using the provider's 
private key and die decryption methody stored as an element 143 and method 141 iri (he provider 
database 1 1, or otherwise made available to the receipt method 141. 

This security technique is not limited to public/privatb key encryption systemis, but can be 

10 applied to any form of en^yptioh where data and/or meithods supplied by the provider are 
necessary to accomplish atttoniatic ienciyption at the point of message origination (the 
consumer), as well as automatic decryption at the point of message reception (the provider). The 
specific encryption protocol or algorithm is not a limiting feature of the invention. 

~ One particular advantage of a communications object system in this respect is the ease 

15 with which multiple public keys may be used. Multiple keys may be included witfiin a single 
conuiiuiiications object,' or a single key riay be constantly changed ^ 

updates, or both techniques can be used together: Since encryption can be applied automatically 
by the consumer programr22, the encryption method I4r can programatically or randomly chose 
fixjm among the available public keys. By including an indentifier value 161 within each public 

20 key element 143, and including this unencrypted identifier value in the header of the encrypted 
message objects 1 10, the provider program 12 can also automatically identify and apply the 
matching private key element 143 for decryption. The use of multiple rotating public keys 
significantly reduces the risk of security breaches if any one key combination is broken, and 
increases the effort necessary to compromise the security of the messages. 

25 The authentication of public keys and digital signatures can also be automated via the use 

of authentication objects, a special type of service object. Authentication objects and servers will 
be further discussed below. 

An example illustrating the application of encoding control and automation using 
communications objects is shown in FIG. 21 . A provider using the provider program 12 has 

30 created and distributed to a consumer program 22 a communications object instance 35. This 
communications object contains a WPFileSend method 141, plus such additional elements, 
methods, and rules (143, 141, 140, FIG. 3) as are necessary to govern the encoding and 
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, ti^paoisaop .of >yQrd.pp[5es.sii»;g doc)iinw»ts.frpm consumers. A consumer wishes to transmit a 
y«)r^ prp^^ssipg-file 951 produced by a word processing program 950 to the communications 
P'aect .pipyider. The word processing program 950 runs concurrerttly with the consumer program 
22 op the coi<sumer cpmputer 2> The coinsinner invokes a command witijin the woid processing 
5 ppgrtm 950 toexeciite.amwjro prpgrain 953 siidi as tiiQ^ayailable within popular <\vord 
prpcessprs such, as Kficipsoft Word ftopi Microsoft Coiporation and WordPerfect from 
WordPerfect Cojrporation. The macro, program 953 makes an API call to the consumer program 
22 (stqj 960) which returns a list of the available communications objects w*ich support word 
processing file transfer (step 96 1 ). These choices are presented to the consumer in a menu or 

10 dialog box. Alternatively, the macro program 953 could retain an internal list of frequently-used 
word processing file recipients. If a communications object represented multiple recipients, the 
macro program 953 could make additional calls to the consumer program 22 to present such 
menus or dialog boxes as were necessary to determine those subchoices. Once a particular 
recipient or recipients were chosen, the macro program 953 would make one or more calls to the 

15 consumer program 22 for the input options necessary to execute the communications object's 
WPFileSend mediod (step 962). The consumer program 22 would return the necessary 
parameters, including the provider's choice of preferred word processing document formats, 
message categoiy options, enciyption options, notification options (such as priority), return 
receipt options, event logging options, accounting options, and message attachment options (step 

20 963). Those which require consumer, input could be presented in one or more additional dialog 
boxes. 

Once the consumer has provided this input, the macro program can use the provider's 
choice of preferred word processing formats to save tiie consumer's designated \yord processing 
file or files 952 in that fomiat (step 964). If the optimal format is not possible (due to word 

25 processing program version differences, conversion filter capabilities, or other factors), the next 
most preferred format can be used. Once the file or files 952 have been saved, die macro program 
953 can make a final API call to die consumer program 22 (step 965). This calls tiie WPFileSend 
method of the seieeied communications object and supplies the name of die word processing file 
or files to be sent together witii tiie additional parameters to Uie method. The WPFileSend 

30 method executes a series of steps witiiin the consumer program 22. First, it uses the provider's 
preferred compression format to apply a compression algoritiun such as PKZIP from PKWARE, 
Inc. or SIT from Aladdm Systems to die word processing file or files. Inc. (step 966). As wiUi die 
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word processing file format, if the most preferred "cbmp format is not available, the next 
most preferred format can be lised The WPFileScnd method then uses the provider's public key 
to apply an encryption algorithm such as RSA from RSA Data Security, Inc. 16 the word 
processing file or files (step 967). Once the word processing file or files are ready, in step 968 the 

5 WPFileSend miethod creates the ^)propriate messaige object or objects (8 1 0, FIG. 1 7). Tlien the 
WPFileSend method creates ah e-miil niessage or messages 956 and applies the encoding format 
such as MIME, BinHex, or UUEhcbding specified by the communications object 110 to attach 
the message object or objects (ste^ 969). La^y, the e-mail message of messageis are tnuismitted 
hade to the provider computer 1 1 (step 970). 

10 When the e-iiiail message 956 is received by the provider program 1 2, the WPFileSend 

method stored in ftepiibvider database 1 1 is executed. This performs each decoding step in 
reverse order. First the e-mail message 956 is decoded to produce the message object attachment 
or attachmoits (st^ 971). Then the mess£^e object or objects are read and processed to 
determine the subsequent decoding steps necessary (step 972). Using the fimction calls and 

15 parameters supplied in tfie message object, the word processing file or files 952 are decrypted 
(step 973). The same procedure is followed for decdmpression (step 974). Next the file or files 
files are saved to an appropriate storage directory (step 975). Finally the provider's notification . 
preferences for the WPFileSend method are followed (step 976). For example; this step may 
involve placing a notification message element (21 1, FIG. 4) and a hyperiink to the file or files in 

20 the provider's notification report. Clicking this hyperlink will open the provider's word processor 
958 and load the word processing file 952, as is the convention with files of specific MIME types 
submitted to a browser 50, In this way the provider can view the fiilly ttanslated word processing 
file or files 952 in the optimal format without expending any human effort to receive, 
decompress, decrypt, or translate the file fomiat 

25 Trmsnnissipn Control 

As discussed earlier, a communications object system can control and automate 
commiinications via any type of commimications network to which both the provider and 
consumer have access, the particular communications network used is not a limiting feature of 
the invention. For example, many providers and consumers share access to three common 

30 communications networks: the Internet (a data communications network), the telephone system 
(a voice/fax/data communications network), and the postal system (a physical commiinications 
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network). Communication^ objects themselves are typically transmitted and updated via.^ data 
conuniuucattons network such.iUt the Internet (aldipugh alternate conuiiimjcaiidns. networks such 
as the telephone systpm or postal systeiQs could also be used). However, these objects can be 
used to oontiol communications, via other typje$ of CQmmunicatipns nejv^prks ^such as voice, fax, 
5 and po^l To do so requires that the provider program 12 or consumer program 22 include the 
external drivers or function calls necessary to iiiterface with these cqnmlunicatipns networks. In 
the case of telephone conmiunicatipns networks, this could be accomplished through a serial 
interface driver and an appropriate voice/data/fax modem hooked to the provider*s or consumer's 
computer or local area network. Alternatively the programs 12, 22 could support operating 
10 system telephony API calls such as the Telephony Applications Programming Interface (TAPI) 
provided with the Microsoft Windows family of operating systems from Microsoft Corporation. 
For postal networks, the interface could be accoinplished through a print driver capable of 
producing machine- or human-readable printer output This output could be printed directly on 
the transmission media, such as a postcard or envelope, including within the transmission media, 
15 such as within an envelope, or applied to the exterior of the transmission media, such as a label 
or routing slip. Incoming transimissions via a postal network can be processed via manual data 
entry or automatically via the use of a print seamier or barcode reader. Alternatively the 
programs 1 2, 22 could output or input digital files from removable magnetic or optical media, 
such as floppy disks or disk cartridges, that are transmitted via postal networks. 
20 Transmission control is accomplished using a conununications object system in the same 

manner as encoding control. Using the provider program 1 2, the provider supplies withm a 
communications object (110, FIG. 3) one or more elements, methods, rules, (143, 141, 140, FIG, 
3) or any combination of these governing the preferred communications network to be used for 
. any conununications transmission resulting from the conununications object. Once the 
25 commimications object 1 10 is acquired by a consumer, any conununications transmissions 
resulting from the communications object, whether generated manually by the consumer using 
the consumer program 22, automatically by the consumer program 22 itself, or automatically by 
another software program accessing the conununications object via an API, will deiemine use 
the most preferred communications network available. The determination of the optimal 
30 communications network is a cooperative endeavor betweent the provider and consumer. The 
provider can indicate the range of available choices and the provider's preferences within this 
range. The consumer program 22 can automatically, or manually with the consumer's input 
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detenmne the ckinsum^s prefer 

Iran^ssioh control can be illustrated vfith a coininuhications object which offers 
sofbvare technical support options. Referring to FIG. 3, a ]^^e 142 within the communications 
object 1 10 can include elemishts 1 43 which allow a cohsumef to access technical supix>rt 

5 resources via e-mail, fax, postal niail, or voice. Each elemwit 143 is associated with a method 
141 governing the cbmmunicatibns netwdrk to be ijsed for that type of transmission. E-mail 
options can invoke a SendEMail method 1 43 ^^ch can obtaiiri from the element 1 43 all data 
necessary to address the e-niail, specify the subject line or subject line subsections, add other 
carboiii copy or bliiid carbon copy recipieriti and include any additional data in the body of the 

to message or as attachmeints to the message (data exchange control is further discussed below). 
The consumer ca^ enter the balance of the message manually via a text input field on an HTML 
form, or by designating an appropriate computer file or files, the SendEMail method can then 
send the e-mail via Internet SMTP. Fax options can similarly invoke a SendFax method which 
can obtun from the element 143 the provider's fax number, calculate any necessary prefixes or 

15 iong distanceareacodes, and compose automatic cover pages and body pages. Again the 

consumer can: enter:the balmce of the naessage;inaniially via- ^ ah HTML form, . 

or by designating an appropriate text or computer file or files.' The SendFax method can then 
transmit the:^fax'.message:via:roodel or. fax-API'interface. Postai'mail options:are handled using a 
similar SendPpstal method; In this case the output is printed to a local or network prihter. Fully 

20 addressed and barcoded postcards, envelopes, or labels can be printed automatically depending 
on the capabilities of the consumer's printer. These can include human or machine-readable 
routing codes for use when the postal delivery is received by the provider. Voice options can call 
a Send Voice method that can provide powerful control over telephony. For example, beyond just 
autodialing a phone nuihber obtained from the element 143 (which, like a telephone speed dial 

25 button, the consumer need never see), a SendVoice method may use additional touchtones to 
navigate a receiving voice menu or voicemail system until it has reached a specific destination. 
At this point it may visibly or audibly notify the user that the line is ready. Another option with 
approj^riately equipped computers is for the SendVoice method to allow the user to record a 
. voicemail message immediately using a microphone and soiihdcard. Then the SendVoice method 
. 30 can completely automate the transmission of this voicemail message in the background while the 
user does other work. If the provider is appropriately equipped, a SendVoice method could also 
coordinate the alternating transmission of data and voice in the same telephone call. Alternately, 
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it coiil^l eijaplpy protocols suqh as VpiceView from Radish Sofhvare, Inc; for mixing data and 
voice in one telephone session. 

When a data cprnmunications network, such as the internet, is available to both the 
provider anc} consumer, many cpnunumcations transmission can be more efficiently and 
autoniatically accomplished via this channel. However, certain tasks such as the shipment of 
physical goods or live voice telephony must occur via alternate conmiunications networks. 
Because they can operate so.efficientJy via a data communications network such as the Internet, 
communications objects are particularly well-suited to the scheduling, tracking, and coordination 
of communications transmissions taking place via alternate communications networks. 
Communications coordination, will be discussed fiuth^ below. 

Receipt and Acknowledpment Control 

In conventional communications systems, the vast majority of communications message 
processing must be done by humans. In a communications object system, both providers and 
consumers have a powerful way to automatically control the processing that takes place when 
specific communications events occur. Like many other aspects of a communications object 
system, this control is cooperatively shared by the provider and consumer- The provider can 
specify what processing the provider wishes to have take place. The consumer can place limits 
upon what processing a provider is allowed, as well as specify additional processing the 
consumer wishes to have take place. 

The primary mechanism for controlling automatic event processing within a 
communications object system is the receipt method. A receipt method is one or more methods 
which are executed automatically upon receipt of a communications object. Receipt methods are 
identified by their method type as described above. Receipt methods can be associated with any 
type of communications object 1 10, including communications object updates, composite objects 
81 1, and message objects 1 10. In addition to the receipt methods included by a provider, a 
consumer can also assign his/her own receipt methods to a communications object. Like any 
method, receipt methods can call other methods, so a series of receipt methods can be chained in 
a particular order. 

As shown iii FIG. 15, receipt method processing is a standard part of communications 
object reception processing. Receipt methods assigned by the provider are executed first (step 
721 ), followed by any receipt methods assigned by the consumer (step 722). The provider's 
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methodsare given execution priority because t rozi^^ receipt meiJickls could result in 
program stale changes the provider cannot predict. 

Perhaps the most common example of how a provider cian lise receipt methods is 
acknowledgment messages. Although ackik>wledgmdlt inessag can take any form arid be sent 

S to any receiving, program (or human); in a pfefetred embodinient they are transmitted as message 
object instances 810 bade to the providei* program 12 or ta a distribution server 32. Alternatively 
they can be sent to anbUier computer program designed by ike provider to receive the message 
object instances 810 or another stnictured message format Acknowledgment messages are used 
to confirm receipt of any type of communications object; including another message object. 

10 Acknowledgment messages can be produced by a consumer program 22 to acknowledge receipt 
of a communications object from a provider program 1 2. They can also be produced by a 
provider program 12 to acknowledgment receipt of a message object firom a consumer program 
22. The ability of a conununications object system to produce and process ackno^edgment 
messages automatically is another strong advant£^e it holds over other communicadons systems. 

15 This is because with most convmtional communications systems, acknowledgment messiages are 
either not. produced at all, or if they are, they must be processed manually by the use*r.-If 
acknowledgment messages are not produced at all, the user has no way to giiarantee that 
important^^^coHMnunications transmissions have succeeded. If 

the user, the user is forced to periodically check for receipt of the acknowledgment message; then 
20 take appropriate action if it has not been received. Automatic acknowledgment processing shifts 
this burden entirely to the provider and consumer programs 12, 22. The user can simply instruct 
the program to alert the user if an acknowledgment message has not been received within an , ' 
expected period. The user is then able to forget about the matter completely, knowing the 
program will notify him/her only if there has been a problem with the transmission. The program 
25 can also be instructed to attempt automatic retransmissions before notication; further reducing 
the potential workload on the user. 

The data structures necessary for acknowledgment automation are shown in FIG. 3. The 
primary structure involved is the acknowledgment association 121 . This is a one-to-one 
assocation between a recipient instance 1 20 and a conunimications object instance 1 1 0. It 
30 includes an AckDateTime attribute which is a date value and an AckFlag attribute which is a 
. logical value. As explained earlier in the distribution process for coxnmutucations object or 
object update (steps 552 - 562, FIG. 12), the AckDateTinie value is set to the the datie/time of 
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distribution plus the acknowledgment intervals The acknowledgmeitt interval is taken fiN>m the 
Acklnterval attribute of either the communications object 1 1 0 or the recipient 1 20, depending on 
which the provider chooses to govern acknowledgment The AckFlag value is also initially set to 
FALSE. 

5 The steps necessaiy for acknowledgment automation are shown in FIG. 1 . When a 

consumer program H receives a communications object instance 35 from a provider program 1 1 , 
the consumer program 22 executes the object's receipt methods. By including an SendAck 
receipt method in thp communications object 35, the provider can cause an acknowledgment 
message 33 to be retimied to the provider program 12. The SendAck method simply generates a 
10 message object instance (81 0, FIG. 1 7) that includes another SendAck receipt method and the 
recipients database system ID (1 00, FIG. 3). When the acknowledgment message object 33 is 
received by the provider program 12, its SendAck receipt method 141 is executed. Being a 
polymorphic method, the operation performed by the SendAck method 141 at the provider 
program 12 is different than at the consumer program 22. Referring again to FIG. 3, the SendAck 
15 method 141 first uses the system ID of its parent conununications object 1 10 and the system ID 
of its originating recipient 120 to query the database for a acknowledgment association 121. It 
then changes the value of the AckFlag attribute to TRUE. The AckFlag attributes of all 
acknowledgment associations 12 1 are maintained in this way. Now all that is required to 
complete acknowledgment automation is for the provider program 12 to periodically execute a 

20 scheduled event 1 1 7. This event executes a AckMonitor method which queries for all 
acknowledgment associations 121 \^diere AckDateTime is equal to or less than NOW and 
AckFlag is FALSE. Those instances meeting this criteria represent recipients 120 from whom 
acknowledgment messages have not been received in the alloted interval. The AckMonitor 
method could then take appropriate actions. For example, it could execute a designated 

25 notification method to notify the user, such as placing an entry in the user^s notification report. 
Notification control is fiirther discussed below. Alternatively, the AckMonitor method could 
automatically retransmit the appropriate communications object instance 1 10. Each time it did 
this it would increment the AckDateTime value of the acknowledgment association 121 by the 
appropriate Acklnterval. It would also increment the integer value of the RetryCount attribute by 

30 one. If the acknowledgment association 121 continued to fail the AckMonitor check, each 

subsequent retransmission would continue incrementing the ReuyCount attribute until it equaled 
a ReuyThreshold atuibute value stored in the global preferences instance 103. At this point user 
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Qotification could be triggeied; as well as other appropriate actions de^gnated by the provider, 
. such as deletion or inactivation of the recipient instance 120. 

Like any other message object, ackriowlddgment messages can also be used to report 
back useful information to the provider about the consumer, such as statistical or usage data. 
5 Data exchai^e control and reporting control will be further discussed below. 
When communications objects are 
acknowledgment meissages can be used to delete recipirats 120 >Vh6 do hot wish to continue 
receiving cdmmunications object tq>dates. This is accompli^ed iii ^he saihe manner as consumer 
distribution control using the push technique, described above. In this case, the SendAck receipt 
10 method presents a form to ttie consumer allowing him/her to edit the logical vsilue of a Subscribe 
element 143. The resulting vahie is retiuned with the acknowledgment miesssqge object instance 
810. Upon receipt by tiie provider program 12, a negative Subscribe element value causes the 
SendAck method to delete the association between the recipient 120 and the conamunications 
object 110! 

15 Acknowledgment messages can still be used even when the distribution method uses the 

pull technique. This is accomplished identically to the above except for the following. First, the 
acknowledgment message object instance (810, FIG. 17) returned to the provider program 12 
includes such additional data about the consumer as is necessary to create a recipient record 120. 
Second, if die recipient record 1 20 instance does not exist in the provider database 1 1, the 

20 SendAck method needs to create it, and also create the association 121 between the recipient 
120, the communications object 1 10, and one or more methods 141, including an update method. 
This specialized use of an acknowledgment message object 1 10 is refened to as a registration 
message. Registration messages are important for three reasons. First, registration mess£«es can 
be used to track coinmunications object distribution and usage even vJhtn the provider does not 

25 have the capability to distribute updates using the push technique. An example is when an 
expensive, high-powered web server is used for high-volume distribution of a conununicatipns 
object, but an inexpensive personal computer and e-mail account is used for tracking 
commiinications object acknowledgment messages. Second, legistration messages can be used 
on an intermittent basis by only including the SendAck receipt method in selected 

30 cofiununications object updates. This allows distribution statistics and other data to be gathered 
periodically rather than with every update. Third, if the acknowledgmem message object 1 10 
includes the e-mail address of the consumer, the resulting list of recipients 120 created by 
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fsgl^f^^oB messages .pjan dlow proyida-.tQ. convert the cpmEnunicatioris object lipdate' 
method from pulj to pusJi, Convetaon bietv^e^ finther.below. 

ADPther cominpn sample of ^ prgividet-assigned receipt method is scheduling pblHng 
ev^te ^heai a,cpmmunications object-uses the pull technique for updating. A SetPdIling receipt 
5 method aih pause the previou? polling even to be deleted ind the next; pblling eveiit to be' 
scheduled, A^ith composite coinmumcatidns objects. #li 17), a GetCoihponents redeipt 
method can govern the updating of each component object to which the cdnsuiner is subscribed, 
Thi? allows a composite object to control the updating of all its component objects as d^ribed 
in the distribution control section above. Update control will ■be described fiirther below. 
10 Another example of a provider-assigned receipt method is r^istratibh. Certain 

communjci^^pns objects such as service objiects may explicitly wish to register thejnselves or 
their public me^ipds within the consumer database 21 . Object and method registration Will be 
discussed fiirther below. 

The foregoing cases are all provider-assigned receipt methods. A uniqiii feature of the 
15 ittcsent invention, however, is that once a consumer has leceived a communications object from 
a provider, the consumer is- also able to assign receipt methods. Theisfe methods can be assigned 
to the object as a whole, or to specific preference within the object. The data stnichires necessary 
for accomplishing this are shown in FIG. 3..Receipt methods applying to the communications 
object 1 10 as a v**ole can be assigned via an association created between the communications 
20 object preference element 127 and a method 1 4 1 (this association is not shown due to space 
limitations). Receipt methods applying to specific preference elements can be assigned via an 
association between the element preference instance 1 47 and a method 141. 

A common example of a consumer-assigned receipt method is forwanlmg, wherein 
receipt of a communications object update causes that update to be forwanled to another 
25 consumer program 22. Forwarding is fiather described below. 

Consumer-assigned receipt methods can also be used to control data or message exchange 
with other software programs operating on the consumer computer 2 or withm the consuiher's 
local nefworic environmenl. This can be accomplished via receipt methods which call operating 
system methods or the methods of the target computer program. 

30 .Update ContTpl 

One of the most distinguishing feanires of a communications object system is its ability 
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objects, such as those designed fbr dhe^tiihe da!^ excyiige operations^ ni^y hot be persistent in 
the«consumer database 21 and thus not require updating. However evieiy conuhimications object 
that will be persistent iii the consumer databa^ 21 he^ to'te iqkiatad wbeh the proiider mak^^ 

5 chatiges to the object Push-based u]^^^ 

association rule (FIG.. 1 OB) d^cnbi&d above. Pul^based i^dating is acconijjii^ed thrbiiigh the 
use of update methods. As with any other object ihefhod, an update ni^od may be a reference to 
a system method^ an method carried iiitenially ui the object, or a call to a remote method stored 
on another computer accessible via communications histw 3. A commimicatibiis object may 

10 also be associated with multiple update methods. 

When a communications object instance is distributed using the piish technique, updates 
are pushed by the provide program 12, so an iqidate method is not requited in the 
communications object However, an update method may still be employed in this case for error 
correction. For example, if the provider typically distributes communica^tions object ujxiates via 

IS the push technique every 30 days, the provider could include in the communications object a 
receipt method that.creates a sdieduied:event.instance ( 1 17,.FIG1 3) in the:coiisuiher.pf6gram 22 
to be activated in.60 days. With each subsequent update of the coixmiunications object, the 
receipt method would reschedule.this scheduled event instance for another; 60.diys: into: the . 
future. If a push transmission from the provider did not reach the consumer witlun a 60 day 

20 period, the scheduled event instance would be actived. It would trigger the update method which 
would send a message object 1 1 0 back to the provider program 12. This message object could 
contain the e-mail address of the consumer computer 2, the version and date of the last 
conmiunicauons object received, and other such data as would allow the provider program 1 2 
and consumer program 22 to resynchronize after an error condition. 

25 When a conununications object employs the pull technique of updating, an update 

method is used to control the update operation. Pull-type update methods can use any services 
available at the consumer program 22 to initiate an update. In a preferred embodiment shown in 
FIG. 1, an update method initiates a. polling request from the consumer program 22 to a 
distribution server 32. For example, the consumer program 22 can issue a HTTP "Get" request 

30 to Web server using tiie "If-Modified-Since" parameter in die header. The date/time of the most 
recent existing conmftunications object version in the consumer database 21 is supplied as the 
value for the "If-Modified-Since" parameter. TWs value is stored as the LastUpdate date attribute 
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of the communications Qbject (110, RG. 3). If the date/time of the the communications object 
markup file qh the. Web siprver h^ not chang^etJi the Web scaver TCtums a »«sponse code 
iiKiicatiiig "no chang?", and! the upiiate method m}l schedule tlie ne?rt polling event. If the date of 
the file 35 stored on the Web seryer 32 is newer, the Web server returns the conunimications 
5 object nm;kup file 35, and processing tegi^ 16. 

Referring again to FIG, 3, the triggering of update methods is typically controlled by a 
scheduled event instance 1 17 in the conswner program 22. As described above, this scheduled 
event instance 1 1 7 can be created by a receipt methoji, executed vi*en a communications object 
or object update 1 1 0 is received. It can also be scheduled or rescheduled by an uj^e method 
10 triggered by a scheduled event instance 1 1 7. This combination of using receipt methods and 
i^jdate methods to ciontrol scheduled event instances 1 1 7 provides comprehensive control over 
update events. This is further augmented by the ability of receipt and update methods to use any 
data available to them within die conununications object 110 or die consumer 4atd»ase.21 to 
^ . make update decisions. For example, update events can he scheduled based on a specific, periodic 
15 interval or specific date/time set by die provider. By the use of preference elements, the provider 
may also allow the consumer to choose an update interval or date/time, or to choose from within 
an update interval range or data/time range offered by the provider. The provider can also let the 
update method determine a random date/time within a periodic interval or date/time period. This 
last apjwoach. commonly referred to as a "back ofT, can be useful for controlling server loads. 
20 For instance, a provider may publish a weekly newsletter on Friday afternoons at 2 p.m. Eastern 
Standard Time. By specifying that the receipt or update method schedule the update polling 
event for a random time within the next 3 hour period, the provider can efficiently disuibute a 
very large volume of updates within that 3 hour period without overioading the server. Receipt of 
update methods can also use other logic or data to control update polling. This might include 
25 factors such as the total age of the communications object in the consumer database 2 1 ; the 
frequency with which the consumer has viewed or acted upon the communications object; costs 
or fees associated with an update; or other criteria. The specific algorithm or algorithms used lo 
control update scheduling are not a limiting feature of the invention. The consumer may also 
wish to have the consumer program 22 dypamicaly reschedule update events depending on other 
30 factors such as the tinie of day, the interval since the program was last run, local or Internet 
network uaffic levels, the consumer's own system activity level, other system or environment 
variables, disk space availability, or other factors. Update methods can also be triggered. 
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Diffenait iipcUie methods, or differing parameters to one update method^ can also be 
active depending on the consumer's preferences or other riilesi determined by the provider or ' 
cbinfiuimef. For examrile, a dififercht polling interval may be associate with one or more 
5 notification elements, so the polling frequency may be determined by which hotiftcatioh 
elements a cohsunier has activated^ Notification elemeiiis are further discussed below. 

Th^ nature of comniuhications 6bje6t ai^hitecttire makes it easy for a provider to convert 
a communicitidm object 110 from ptfih to pull updating and vice versa. To convert from push to 
pull updating, the provider need only add a pulUbased update method to the communications 
10 object, than distribute it via the push technique to all recipients 1 20. As soon as it is received by 
eadi recipieht ttie object will begin to use pitll updating. The conversion from pull updating to 
push iipdating is alinost as strughtfbr^^ 

communiditions object 1 10 that will return a registration message to the provider program 12 or 
a distribution server 32. As described above, registration messages create or update a recipient 
15 instance 1 20 and its association with the communications object 1 1 0 and an update method 141. 
As each registration^messagens receivedrthe recipient .is* converted to'a push update method. The 
provider need only maintain the piiU version of the communications object 110 on a distribution 
server 32 until the provider believes all outstanding copies of the object have relumed a 
registration message, 

20 In certain cases it may be advantageous to combine both the push and the pull techniques 

of updating for a single communications object 1 10. For example, a provider may wish to use 
pull updating for distribution of a monthly newsletter, but also wish to be able to distribute an 
update via tiie ptish technique when very timely news occurs, such as a special event. In this case 
the provider can use pull updating in the conununications object 1 10, but also include a receipt 

25 method tiiat returns a registration message from tiie constimer the first time flie conimunicatibns 
object 1 1 0 is received. (Consumer registration information can be updated whenever the 
consumer changes it. Registration updates will be further discussed below.) These registration 
messages create a ^cial association between the recipient 120 and conununications object 110 
vAich has a PushSpecial attribute (not shown in FIG. 3). Recipients 120 whose association with 

30 a communications object 1 1 0 has a PushSpecial attribute are ignored during standard ' 

communications object updates. However when die provider needs to distribute a push update, 
die provider can set a PushSpecial flag for the communications object 1 10 using the edit object 
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fonn (322, FIQ,. 9), When this.flafe is sel, all recipients 1 20 associated with the cdmmunicaiions 
object 1 1 Q will rgceivp the update via the push techmque. Altemativfely, the provider may choose 
to <Msttibme.a injessage object 1 10 to all recipients: 120 who have a PushSpecial association with 
a coflirnunications objept 110. This message object can include a receipt method that triggers an 
5 update via the pqlj technique. In this fashion a sinall message object hiay be distributed via a 
push medi^m such as e-mail in order to trigger the downloading of a much larger update via 
another medium such as the World Wide Web or FTP. 

One communications object can be used to control the updating of other coifmnunications 
objects. F<M- example, the receipt method for a co&iposite conlmunicatioiis object can trigger the 
10 updating of each of its component objects. To illustrate ftis, tefex to FIG. 20 and the preceeding 
discussion of consumer distribution control using the pull technique. A composite 
communications object 900 can contain multiple page subscription element instanced (853, FIG. 
1 8) corresponding to its component communications objects 901 . Each page subscription 
^ element instance can include an attribute for the current version value of the cone^onding 
15 COTiponent object 901 . This version value attribute can be maintained using a rule 1 40 that - 
updates the version value of the page subscription element instance when the version value of the 
component communications object 90 1 changes. When the composite communications object 

900 is updated, its receipt method can compare the version value in this attribute with the version 
value of the corresponding component object 901 currently stored m the consumer database 21 . 

20 When, the version value has changed, the update method of the corresponding component object 

901 can be executed to update the component object In this manner the component objects 
themselves do not need to be polled for updates. This same technique of "indirect updating" can 
be applied to any set of communications objects, where elements in one communications object 
are processed to trigger the updating of other related communications objects. In this way, for 

25 example, a single communications object at a web site could be used to check for updates on 
many additional communica^tions objects on the web site or related web sites. 

Another highly efficient up4ate control technique, referred to as update query control, 
requires the use of database program operating on a disttibution server 32. In a preferred 
embodiment, this can be accomplished using a distribution service object 1310 and a distribution 

30 partner server 1302. These will be fialher discussed in the distribution service object section 
below. With update query control, the communications object 110 controlling the updating need 
not contain any direct references to the specific communications objects or component objects 
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being updated. Riather the cdottdHihg: coxhmtmiirat^ object 1 1 0 can cohtain one or itiorb data }; 

exchange elCTiehts 143 and ds^ exchMge methods 141 wfiicli fmi<^on £ls's^^ 

(Data exchange elements and data exchange thethods will be furfter explained in the data 

exchange control section below.) The-<iata exchange ihethbd 141 can first eixecute a query of the 

5 consumer database 21 fortil communications objectis which riiatcKthe query crifieria. For 
exanaple, a composite communications object 900 coiild query for all its compoheht 
communications objects 90 1 . The query restilt includes the UID aiid current version value of 
each component object 90 1 . The data exchange method then uses the result set id perform a 
second queiy of the distribution server 32. The distribution server 32 would return each 

10 component object 901 for which the version value on the distribution server 32 was greater, in 
this manner a single conununications object could be used to very efficiently tipdate thousands or 
even millions of conmiunications objects stored on high performance database servers. 

This process can be niade eVeii more efficient for the consumer by 
index of provider UIDs and the communications objects 1 10 with which they are associated with 

15 on the distribution server 32. This process is further described in the directory service object 
section below. 

Another update control approach that can be used with both the pull and push techniques 
is version monitoriiigr Version monitoring can be employed with either the push or the pull 
technique; Version monitoring uses a rule l40 to monitor version values included in message 
20 objects passed between the programs 12, 22, and 32 to detect when a communications object 110 
needs to be updated. Version monitoring is further discussed in the sections on data exchange 
control and data archiving control below. 

NQtificfition Control 

One of the greatest advantages of a commiuiications object system over other 

25 communications systems is the ability it gives information consumers to control notification 
about communications events. The fimdamental reason for this is that within a communications 
object system all ihessages are transmitted and received as some type of conununications object. 
This allows messages to be "pre-processed" by the consumer program 22 or provider program 12 
using data or methods from one or more coniriiunicatiohs objects already present in the consumer 

30 database 2 1 or provider database 11 . This preprocessing allows these programs to do a large 

amount of the sorting: filtering, and notification work that otherwise would require huinan effort. 
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In a (^nunii^icafi object system noilSc^tion^cbn achieved primarily through the 
use of notificadon mediods l41vi^otifi^ HOt Wd notification elements 141. 

Collectiyjejy .tjje^^^ ar? :referred to .as notification cpinponentS; Notification methods 141 can 
operate oil. a c^mmunic^ipns objeet as a wholCi or they can be associated with specific > 
5 notificatiop el?|i\g]|^ 143 cpntaiiiecl within a communications object. Since notification elements 
143 desOTbe the n^^re of other dato or «v^nts about which the consumer may be notified, they 
are one pf the principal metadata.cpnstructs of the present invention. Gommunications objects or 
object updates can carry multiple notification elements 143. Each notification element 143 may 
also be associated with miJtiple other elements 143 such as message elements 143. Consumers 

10 can accept default notification methods 141 assigned to each notification, element 143, assign 
other system notification methods 141, or create and assign their own notification methods 141 . 
The combinatioji of these capabilities provides a powerful means of active messaging. 

As described above, notification elements 143 have a special type definition which the 
consumer program 22 uses to trigger notification processing. FIG. 4 illustrates a basic example 

15 of a notification element instance 201 called a topic element Topic elements allow providers to 
specify interest topics on which consumers can choose to receive notification of new messages. 
A topic element 201 includes the attributes of element class 143 , namely system ID. name, 
description, version, NewFlag, and HoldFlag. It also includes an attribute NotifyFlag which 
accepts a logical value for the default notification state set by the provider. A topic element 201 

20 is associated with one or more message elements 21 1. A message element 21 1 carries the actual 
content of the message about which consumers can choose to be notified. It includes attributes 
for headline, headline link, body, and body link. The headline is a text field that will be displayed 
in a notification report for the consumer. The body is a text field that contains the body of the 
message, which can be displayed on its own report page. By default the headline can be linked to 

25 the body. Optionally the provider can choose to supply a headline link attribute, such as a.URL, 
which would link the headline to another web page, communications object, or other resource. 
The provider can also supply a body link which would link the message body and another web 
page, communications object, or other resource. Alternatively, the body can be an HTML field, 
which allows the provider to completely control the formatting and presentation of the body page 

30 as well as provide any number of URL links within this page. 

The topic element 201 illustrated is.a simple "on/ofi" notification element. Notification 
elements may also be of other composite types which give providers and consumers more 
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latitude over notilicdtioti cohtrdl. Specific^ly, the comptisite^ type coutd ihfelude additional fields 
1 52 of a primitive type integer range vWbich allow the hoiificaUon eleiheht to have a " threshold" 
value rather than an dn/off setting: Thresholds let providers add a valuative diihehsioh to 
comiminications events; For ihstance; a ndtificatibn eleiherit aliout new prbduct smfiduhcements 

5 could have a range setting of one to five indicating the imjpk}ilahce oif the~ ahhduhc^eht . 
Consumers can how choose fibih a gradient of interest levels' in this td^pic rather than just an 
on/off setting. Another use of thre^dlds is a frequency threshdld. iFrbqiiehcy threishdlds ^low 
consumers to control the fi^iiency of messages they' will receive relatield to a specific notification 
element For example, a consumer could choose to receive a itiaxMiuh of three messages on a 

10 specific topic in any 3i 0-day period. The hotificatidn mi^thod associated with this element would 
track the messages associated with this notification element and turn off hdtificiatioh for any that 
exceeded this frequency threshold. The spedific configuration of notification elem^ts used is not 
a limiting feature of the invention. 

The use of notification elements and notification methods to control niessaging involves 

15 the following sets of steps. First the provider uses the create new element form (341, FIG. 9) in 
the provider program 12 to create notificaiiion'elementf instandes for each conuntm 
vsiiere the provider wishes to allow consumers to control notification. FIG. 22 illustrates a typical 
create new element form for notification elementsrThe provider inputs the name and description 
attribute for the information topic covered by the notification element. For example, the name of 

20 a notification element for a company selling a software product might be "New Version 

Announcements". For an on/off-type notification element, the description might be, "Includes all 
new version announcenients, both minor and major upgrades**. For a range-type notification 
element, the description might be "Choose from one to five. One receives only full point upgrade 
announcements. Five receives all new product announcements, including weekly maintenance 

25 patches." A list of these notification elements would appear similar to the table of contents for a 
newsletter, or the items on a customer interest survey. The provider can assign notification 
elements to one or more pages (142, FIG, 3) which in turn can be assigned to one or more 
communications objects (110, FIG. 3). The provider may consolidate notification elements on 
one or more pages specifically for this purpose, or int«^perse them with other element types on 

30 various pages. Optionally the provider can also create the initial versions of each message 
element or other type of elerhent associated with each notification elemeiit. • 

When the communicaUons object containing the notification elements is transferred to the 
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cons^er progr^ 22, the prefear^ce values for each notificatibn element are editable by the 
consumer. As silQwn in FIG* ^4, these preference values are. stored in an tnstsuice 22 1 of the 
element prefereiices class 147. This instance inhiaits the logical attribute NotifyFlag from the 
nQtific^tion elcgpeiit instance 201. Th?. value, for this field is represented by a checkbox next to 
5 the name and description of the notification element 202 when the cohsunier is editing any form 
containing the notification element. This could be the selected page form (612, FIG, 14) or the 
edit object {qr^ (6,12, FIG. 14), The selected page fprm would present the notification element 
in the context of the other elements on the page. The edit object form allows all preference 
elements for the object, including all notification elements, to be edited at once. FIG, 23 
10 illustrates how notification elements on a typical edit object fonn might appear. 

When the provider wishes to transinit infonnation related to a notification element, the 
provider uses the edit selected element form (342, FIG, 9) to create or edit the message elements 
21 1 or other elements associated with one or more notification.element The provider does this 
for all messages or other notification events the provider wishes to transmit in a particular 
15 conmiunications object distribution. Of course any other communications object or object 
component changes will also be transmitted in the same distribution operation. 

The processing of notification elements in an updated conununications object received by 
theconsumerprogram22isshowninsteps724.728ofFIG. 15. After the appropriate element 
preference associations have been updated (step 717), the consumer program 22 queries the 
20 updated conununications object for all notification elements (step 723). Notification element 
types can be designated by any of the techniques discussed in the data structures sections above. 
One such technique is to include a logical value IsNotifyElement in all such elements. The 
program then begins a loop through each notification element (step 724). First, it checks to see if 
an associated element preference instance (147, FIG. 4) exists (step 725). If not, the notification 
25 element is skipped.^ Alternatively, the program could follow object-level or global^level 

consumer preferences for this case. A special rule could also be followed for new notification 
elements. Alternatively, notification of new notification elements can be accomplished by having 
the provider include one or more special notification elements specifically for this purpose. 
Updates to these special "metanotification elements" can include links to the new notification 
30 elements for easy «iiting by the consumer. For each element where an asscwiated element 
preference instance (221, FIG. 4) exists, the consumer program 22 performs a notification test 
(step 726). For example, the test for an on/off topic element (201, FIG. 4) would be if the 
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NotilyFliag value of the^nsimiei^s' element pitfercnce (221v nG-/4)>yifas equ^Uo 

TRUE. In the nbtification elenierit fails the te^l, the cbiisunier ddes nof desire notification, and 
the program proceeds to the next notification elenient for processing. If the notification element 
passes the test, the program executes the notification methckis the cohsiimer has assigned to the 
element preference instance (step 727). 



10 



Notificatibh methods provide the consiuner with a powerful mechahisih for controlling 
ndtifiication of commtmicaiibhs evimts. Raither tfiari simply maintaining a passive mess^e queue 
as is typical of most e-inail or vdic^hail systems, notification methods allow the consimier to 
specify message processing actions to take tq>on receipt of a ^ecific type of conmiunications 
event or specific communications content The consumer is able to specify such actions because 
of the metadata provided by the notification elemenit 143, and because of the structured format of 
the message data contained in the communications object^ Notification methods 141 may trigger 
any action available to the consumer program 22, subject to the user^s permissions. 



FIG. 4 illustrates two typical notification methods assigned to an element preference 



15 instance 22 1 . A SendEMml method 224 causes each message element 21 1 associated with the 
notification element 202 to be seiit as an e-mail message to an address or addresses specified by 
the consimier. Preferably, such an e-mail message would use as the start of its header a 
signifying string such as "Special Alert: followed by the headline text value from the 
associated message element 211. The body of the mess^e would then contain the body value 

20 fit)m the associated message element 211. It could also contain the headline link value, body 
link value, and other status or navigational information, such as the name of the originating 
communications object, the name of the provider, or other actions taken. An 
AddToNotifyRepon method 225 causes the headline of each associated messs^e element 2 1 1 to 
appear in the consumer's notification report (630, FIG. 14). To set this trigger, the 

25 AddtoNotifyReport metiiod adds a logical NotifyReportFlag attribute 223 to tiie element 

iweference instance 221 and sets its value to TRUE. To display the notification report (630, FIG. 
14), the consumer program 22 perfonns a query of the consumer database 21 for all message 
elements 211 associated with all element preference instances 221 v*ere the NotifyReportFlag 
223 value is TRUE. The actual content displayed in the report is determined by attributes of the 

30 consumer's global preferences (103, FIG. 3). The consumer may wish to see headlines only. In 
tills case each headline can be displayed as a hyperlink. When selected, tiie hyperlink will display 
the message body and body links as a separate page. Alternatively, the consumer may wish to see 
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all headliifes, imessages; and links in the notification report Headlines may also be linked to 
other elements or methods, such as those used for data exchange. Headlines may also ftinction aj 
- a hyperlink directly to another URL anywhere on the Internet Another option is for the 
consumer to see conununications objects for which there are new notifications displayed 
5 differently than other communications objects for vMch there are no new notifications. 

Notification reports may also be sorted according to the settings of the sort form (634, FIG. 1 4), 
or by using various toolbar buttons for common sorting or filtering options. For example, 
notification data could be sorted by communications object name, communications object 
nickname, date, folder, or notification priority. Different standard or custom notification reports 
10 can also be stored and presented as menu options or toolbar buttons. A example of a noUfication 
report sorted by date showing headlmes only for communications objects vrtiich had new 
notifications is shown in FIG. 24. Each notification report entry can include a button for deleting 
the entry from the notification report inunediately, or a checkbox for batch deletion, or both. In 
either case, when the notification report forai is submitted, this button or checkbox causes the 
15 NotifyReportFlag attribute 223 of the corresponding preference element instance 221 to be set to 
FALSE. The format of a notification report is not a limiting feature of the invention. 

These examples are merely illustrative of the actions that can be taken by notification 
methods. Notification methods may trigger any method operation available to the consumer 
program 22. Other examples include sending meissages to other applications running on the 
20 consumer machme 2; sending messages to the consumer's operating system to trigger dialog 
boxes or trigger other system events; creating or controlling a Screensaver display on the 
consumer machine 2; creating or controlling a background desktop graphic or set of graphics on 
the consumer machine 2; and sending voicemail to the recipient. Any combination of 
notification methods 141 may also be used together. The specific noUfication method used is not 
25 a liaiiting feature of the invention. 

Notification methods 141 can also be assigned to communications objects as a whole. For 
example, notification about new communications objects can be controlled through a 
NewObjectNotify method of the global preferences instance (103, FIG. 3). Described fiarther 
above, the use of the NewObjectNotify method is illustrated in steps 704 - 706 of FIG. 15. 
30 Notification at the object level is also usefiil for certain communications object updates. This is 
particularly true for "metamessages" that the provider wishes to transmit to all recipients of a 
communications object, such as a change in business name or ownership, significant structural or 
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operational chianges to a comihuhicatiohs object, or splitting a coxnnnuiicsttions object into 
multiple objects. 

A receipt method 141 can also be used to control notification. For example, a receipt 
method 141 could automatically search the message elements withiii a commxmic^tions object 

5 update for text strings specified try the cbnsianer. As shown in FIG. 3 1 these text strings could be 
stored in an element preferences instance 147 a^ociated with the communications object 1 1 0 
and the receipt method 141. When this receipt method 141 exiecutes, if it finds any instance of 
the search string in the message elements, it causes the notification element or elements 143 
associated with that message element to pass the notificsUon test and triggier the corresponding 

10 notification method 141 . Such a receipt method 141 provides a powerful secondary means of 
notifying the consumer of communications object content which may not be directly related to 
topic elements or other types of notification elements. 

Notification control operates similarly in the provider program 1 2. Here notification 
methods 1 41 are associated prunarily mth message objects 1 1 0. As with the consumer program 

15 22, notification methods 141 can be assigned to a message object 1 10 as a A^ole, to elements 
within a message object, or activated by receipt methods associated with the message object 
When the provider program 12 and constuner program 22 are combined, the same notification 
reporting system can be used for both provider: and consumer operations. Report sorting options 
can allow provider notifications to be shown separately from consumer notifications, or they can 

20 be combined on the same reports. 

Notification methods 141 can also be assigned to system events, and these too can be 
integrated into the same notification reports. For example, a system event can trigger notification 
that a provider is due to release a periodic commimications object update, or a consumer that 
his/her consumer database 2 1 needs to be backed up. 

25 Data Exchange Control 

The ability of a communications object system to automate common commimications 
tasks is perhaps best exemplified by its ability to automate data exchanges between consumers 
and providers. Typical examples include the exchange of contact information, demographic data, 
psychographic data, billing information, product registration information, customer service data, 

30 technical support data, transaction histories, stock feeds, news data, weather data, and so oil A 
commimications object system is capable of automating the exchange of such data to a greater 
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degree than any other existing comniunicatioDS system for five reasons. First, such data is 
abeady stored in a consume database 2 1 in such a fashion as to be available for automated 
access and deliveiy. Second, such data is available in structured, typed formats that allow 
providers to.^^Iy spepify the data tjiey x^uirea Thirdly,- conununira^^ objects give providers 
5 the tool they need to transfer such data ftora the consumer back to the provider. Fourth, message 
objects and the architecture of the provider program 12 allow the provider to automate the 

^ processing of such data when it is received back at the provider. Fifth, the ability of the provider 
program 12 and consumer program 22 to automatically trigger events and respond to message 
objects means a multi-part data ^^change transaction (siuch as a purchase and receipt 

10 . acknowledgment) can be automated throughput. 

The primary data structures involved with data exchange control are data exchange 
elements 143 and message objects 1 10, both desaibed above. Any conununications object 
method 1 4 1 involved with data exchange can be referred to as a data exchange, method. E>ata 
exchange elements 143 in a communications object 1 10 can cadi a data exchange method 141. 

15 Data exchange methods 141 in the consumer program 22 can produce message objects that can 
be transmitted back to the origmating provider program 12, or to any other program capable of. 
processmg the message object Data exdiange methods in the provider program 12 can also 
produce message objects that can be sent to anyiconsumer program 22 containing the parent 
communications object Like any communications object, message objects can contain any 

20 combination of components required to transport and process the data they contain. Data 

exchange methods that produce message objects can be fully automatic. For example, a receipt 
method can produce and transmit an acknowledgment registration message object, described 
above, with no consumer intervention. Data exchange methods that produce message objects can 
also obtain manual data input from the consumer or provider. In a preferred embodiment the 

25 mechanism for obtaining this input is an HTML form. Such input forms are produced and 

displayed by the provider program 12 or consumer program 22 in the same fashion as the forais 
produced for operation of the programs themselves, A typical input form is shown in FIG, 27. 
Each data field that accepts input on the form is an attribute of an element 143. Other text or 
graphics that appear on the form, as further instructions or directions to the user, are other 

30 elements either supplied by the provider or drawn from the consumer database 2 1 or provider 
database 1 1. Any communications object component stored in either of these databases may be 
included, subject to the consumer's or provider's data access rules discussed below. The only 
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difference between input fonns produced by data exchjahge methods and standaxd program forms 
is that an data exchange input form is generated by and processed by a data' exdiange niethod. 
Altemativeiy, user input can be obtained tluough other user mtef&dfbptions including standard 
operating system functions such as dialog boxes and menus. The usfc of a gr^hical user inter&ce 

5 will be specifically discussed below. " " . : r 

Besides input form and message object generation, data exchange control in a 
coimhunications bbject system iiivblves data type control, data persistence control, data access 
control, and data securit)r contooi. Each of theSe must be considered from the standpoint of 
internal data, i.e. data within the provider database 1 1 or cidiisvfiner database 21, ahd external 

10 diata, i.e. data available else^diere within the proS^der's or consumer's computing or network 
environment 

Data type control is required because providers need a way to specify 
require in a specific data exdiange transaction. The data type definition features of a 
commimications object system, as explained above in the data stmcture section, are ideally suited 

15 to this need. By creating a system-wide set of low-level composite type definitions, such as 
Name, Address, and Telephone,- and then nesting these iniside of progessively more 
comprehensive composite type defmitions, such as BusinessCard or Resume, a hierarchy of 
standard data type definitions can be created that are available to all providers andrconsumers. 
This has two very significant advantages. First, as providers design input forms and methods for 

20 data exchange tasks, they can choose from among these standard data type definitions rather than 
needing to create their own composite data type definitions, saving considerable time and effort. 
Second, data type standardization means that consumers need only enter data once into each 
instance of each data type that pertains to them. For example, the cdnstmicr only needs to enter 
his/her name, addresses, telephone numbers, birthdate, and otiier personal data one time into the 

25 consumer database 21 . Frbm that point on all communications objects which need data of these 
types can access these data type instances. This saves tiie consumer data input time and also 
vastly reduces the potential for data input errors. 

Like any communications object component, every composite data type can be identified 
by tiie unique system ID of its type definition (144, FIG. 3). When multiple instances of a 

30 particular data type exist, such as multiple telephbne numbers, the provider can use a data 
exchange method to specify if all instances are desired, or query for selected instances using 
additional criteria, or use an input form to prompt the consumer to select one or more specific 
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instances. Such an input fonn can be generated dynamically by the data exchange method based 
on the presence and number of instances of a data typ^ that satisfy a provider's selection criteria. 
The input fonn can al$o be dynamically generated based on the need for further input by the 
consumer, or to confonn to the consumer's data exchange rules, discussed below. Data type 
.5 standardization can be further extended by; the use of type definition service objects, which will 
be further discussed below. 

Providers can also create their own data type definitions and specify the use of these 
composite data type definitions in data exchange methods. When a provider^specific data type 
can be aggregated or calculated from other system standard data type definitions which are 
10 already present in the consumer database 2 1 , the resulting element can be composed 

automatically by a data exchange method. When a provider-specific data type requires the input 
of new data fiom the consumer, an irq>ut form can be generated by the data exchange method. 
Once submitted, the data can also be saved as a element preference instance (147, FIG. 3) in the 
consumer database 2 1 . The provider can then use the system ID of the type definition of this 

15 element to query for this element preference instance in future transactions. This allows a 

provider to dynamically generate and persistently store provider-specific data type definitions in 
the consumer database 2 1 . A conunon example of such a data type might be a consumer's 
preference between a provider's selection of product colors, such as clothing or paint Storing this 
data locally at the consumer database 21 means that it can easily be included in any future 

20 communications from the consumer. Additionally, such data caii be shared among all 
communications objects or data exchange methods from that provider, as further explained 
below. Another key benefit is that this data can be easily and immediately edited by the customer 
should the. customer's information or preferences change. Such changes can also be automatically 
transmitted back to the provider through the use of data association rules, discussed below. 

25 As with any multiuser database system, shared access to data requires data access 

controls. This control should cover all common data operations such as creating, reading, 
writing; moving, and deleting data. In a commimicalions object system, data access controls need 
to extend beyond human operators to communications objects, since these objects are essentially 
acting as "surrogates" for their respective providers. The key data structure involved with data 

30 access control is die rules class 1 40. Data access rules can monitor all forms of data access within 
the provider database 1 1 or consumer database 21 as well as external data in the provider or 
consumer's computing or network environment. For example, a typical rule governing access to 
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comihtimcatibnis object comj^ or element preference instances might be that only, other 
commiinications objects sharmg the same database system ID (100, FIG. 3) can read, write, or 
delete such instances. This wbuld prevem different providers fitom having access to each other's 
private data. This rule could be modified so that only communications objects sharing a group , 

5 system ID (251 , FIG. 6A), described above, could have access to such data. This would allow all 
communications objects created by employees of the same company, or within a company 
division, to access each othef s communications object component or element preference 
instances. Data access rules can be system-wide, assigned by pioviders, or assigned by 
consumers. An example of a provid^*assi^ed rule would be restrictions oh commimications 

10 object fonvarding, which will be further discussed below. An example of a consumerrassigned 
rule would be that designated personal data, such as household income, must be e^licitly 
authorized by the consumer before it is transmitted in any data exchange. A stricter rule would 
state that more sensitive private data, such as credit card numbers, must be encrypted and require 
one or more passkeys for decryption prior to any data exdiange. In order to protect their 

IS integrity, data access rules can also enforce the ability to add or change other data access rules; 
and also-the:hierarchy in'which.niles.take;precedence3^ 

rules can also be selectively applied by the consumer to particular commimications objects 1 1 0 
or conununicatioiis:object gn>ups,such.as folders.! 15 by.creating,associations.between these and 
a data access rule 140 J The application of rules to control data access within an active database is 

20 further discussed in the aforementioned Active Pfttqbasg SyslemS- 

As the preceeding examples illustrate, enforcement of data access control rules is of 
paramount importance when automatic data exchange methods have shared access to a pool of 
private data belonging to the consumer. One mechanism for enforcing data access rules is 
system- or consumer-controlled encryption of sensitive private data. Any access to such data 

25 requires that the consumer enter the necessary passkey in order to decrypt the data. A second 
mechanism is system- or consumer-controlled authentication of corrununications objects. This 
requires the use of digital signatures and authentication protocols for commimications objects. 
Such protocols are fully described in the aforementioned Acclisd CryptOgTftphY by Bruce. - . 
Schneier, and will be further discussed below. 

30 Data type, persistence, access, and security control can be applied to tiie exchange of data 

external to the provider database 1 1 or consumer database 21 iii the same manner as internal 
data. Such external data falls into three general categories: system data, file data, and data 
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available via extemal q^ieries. System data includes system environment variables, configuration 
variables, and operating statistics. File data includes data available directly via operating system 
calls such as files, persistent system objects, or any other data stored directly in the user's local or 
nQwn>ik compMting environment including removable storage devices mechanisms such as 
5 floppy disk drives, CD-ROM drives, or tape drives. Data available via extemal queries includes 
. data stored in and available through other compytcr programs operating in the usei's local or 
network computing environment, including application programs, database servers, naming or 
address servers, web servers, or any other type of server. 

Data type, persistence, access, and security control for system data is generally dictated 
10 by the features of the operating system and the privileges it giants to the provider program 12 or 
consumer program 22. The use of standard system environment variables such as the ctxrrent date 
and time are central to the operation of these programs, and Has data is fiequently incorporiited 
automatically into communications object componoits. 

For extemal file data, data type control can be particularly useful. For example, personal 
15 computers ninning the MS-DOS or Microsoft Wndows operating systems use a standard set of 
setq) and initialization files including AUTOEXEC.BAT, CONFIG.SYS, WIN.INI, and 
SYSTEM.INI. Standard data type definitions can be created for elements that store information 
about each of these files, such as their,name, size, date, and local directory path. A composite 
data type PCSetj^Files can also be created which included elements for each of these specific 
20 files. Providers can use these standard data type definitions to easily access the contents of these 
files for processing or data exchange. This access can be controlled by data access rules in the 
same way as internal data. This capability is particulary valuable for software or hardware 
technical support, where it can save both the provider and consumer considerable manual time 
and effort obtaining and exchanging this data. 
25 A communications object system allows data persistence, access, and security control for 

extemal file data to operate at two levels. First are the standard file privileges granted to the user 
of the provider program 12 or consumer program 22 by the operating system or network 
' administrator. Second are the rules 140 that can be enforced within the provider program 1 2 or 
consumer program 22 themselves. Data persistence control is particularly relevant to extemal file 
30. data. With the appropriate file creation privileges, data exchange methods ca^ 

creation, modification, and deletion of extemal files on the user's computer system. These files 
can be used for many purposes, including the storage of message attachments, web helper files. 
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log files, troubieshoOtihg files, and files created by or intended for Use by other software 
programs in the user's local or network computing environment. Access control and data security 
enforcement for these files, including encryption and authentication of individuals or 
conunimications objects requesting access, can be handled iri the same manner as internal data. 
5 The ability to access and maiiagie external file storage is particularly valuable in conjunction with 
the use of attachment dements/ Attacliment elements allow a provider to store the specification 
for a file or files as a specific type of ccnnmunications object element 143 which receives special 
. processing during the conununications object gendration and transmission routine. This is shown 
as step S46 in FIG. 12. After the communications object itself is generated for transmission, any 
10 attachment element it contains is processed to determine the file, system object, or other ^ . 
attachinent it specifies to attach to the transmission. Such attachments can be encoded in MIME, 
BinHex, UU encoding, or other attachment encoding format as described above. When the 
communications object bearing the attachment is received by the consumer program 22, the 
attachinent is stored according to. a corresponding receipt method. The attachment can be stored 
15 internally as an element 143.in.the consumer database 21, or externally in the consumer's file 
system; File data exchange control can also be combined withnotificatiomcontroL Eor example, 
amessage element (21 1, FIG. 4) including a hyperlink to the attachment can.also be created for 
inclusion.in a notification report (630, FIG. 13) by the consumer program,22. In this way 
communications object updates can serve as a powerful means of automatically distributing and 
20 indexing one or more external attachment files. 

One of its most powerful forms of data exchange control in a communications object 
system is the ability to automate external data queries and the processing of query result sets:; 
This is because it gives providers a tool to allow consumers quickly and easily set up automated 
queries against any type of data server inaintained by the provider. These queries are easily set 
25 up because they can be composed using any data available in the consumer database 2 1 (subject 
to the consumer's data access rules, as explained above), so the consumer need only enter any 
new data required. The queries are easily automated because the data exchange method that 
executes them can create its own scheduled event instances (117, FIG, 3) to execute future 
instances of the querj'. External query control can also be combined with notification control to 
30 automate notification depending on the query results. For example, a datia exchange method that 
executes a data query for a stock price can notily the consumer if the new price is a certain dollar 
amount or percentage amount changed from the previous price. 
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Data type control is especially useful with external queries. This is because the use of 
standardized data queiy languages such as Structured Query Language (SQL) makes it easier for 
providers to create or consumers to. modify routine data queries. SQL and other approaches to 
standardized data query langu^es are discussed generally in R.G.G. Cattell, Object Dafg 
5 Management - Object-Oriented and Extended Relational D atabase Systems (1 994), which is 
incorporated herein by reference. In a communications object system, the specifications for a 
structured query can be stored as a special type of communications object element 143 called a 
query element. Query elements receive special processing during the communications object 
generation and transmission routine. This is shown as step 545 in FIG. 12. After the 
10 communications object itself is generated for transmission, it is tested for any quciy elements. 
For each query element it cont^ns, the data exchange method associated with the query element 
is executed to perform the query. This could be a query against the provider datab^ 1 1 , against 
another local application acting as a server, against a network database server, i^ainst a web 
server, or against any other server capable of query processing. When the query result set is 
15 returned, the data exchange method determines what further steps to take. These may include 
appending the data to the conmiunications object transmission as a file attachment, creating and 
appending a mess^e object, or otherwise modifying the communications object or its encoding 
or transmission. Query elements thus provide a powerful extension to a provider's ability to 
control and customize conunjunications object distribution. 
20 Data persistence, access, and security controls all apply to external data queries as well. 

Again, a communications object system allows these to be implemented at two levels. Al one 
level, these can be the same controls that apply to the human operator of the programs 12, 22. 
For example, the user's ability to read, write, or create new records in a database server can be 
govemed by a user ID and login password controlled by a system administrator. The programs 
25 12, 22 can simply require the same information to be entered manually. Alternatively, the 
programs 12, 22 could store this information as global preferences that it can submit 
automatically as part of executing data exchange methods. The programs 12, 22 can then 
implement their own layer of internal security. This can include the use of system-wide login 
names and pass>yords, the implementation of rules 140 controlling data access, and the 
30 encryptior^ of sensitive data, all as described above. Data access.andsecurity control is 
particularly useful when data exchange methods employing queries ate executed by the 
consumer program 22 on the behalf of the consumer. Using such conu^ols, a provider.is able to 
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select the subset of consiuhers on a coinxhunicafidhs netwbik 3 siidh as the internet who will 
have access of some kind to one or more databases or databaise servers operated by the provider. 
This control is usefiil when fte provider wishes to charge access fees for the data, to protect the 
data for competitive or security reasons, or to monitor or track access to the data: 

5 By being able to control the exchange of external system d^ file data, and data 

available via external queries in addition to internal data, the programs 12, 22 can automate many 
routine infoimatidn transactibns on data communications networks. This can produce a vast 
savings in the hiuiiaii labor nomially required to exchange such data. The present invention is 
able to furdier increase tMs labor savings by automating the processing of such data once it has 

10 been exchanged. As with other data exchange operations, diis is accomplished through the use of 
data exdiange elements 143, data exchange methods 141, and message objects 110. Any data 
exchange method can produce a message object 1 1 0 that can call itself or another method or 
methods for processing tfie contents of the message object once it is received. As explained 
above, data exchange methods that call themselves are poiymoq)hic, performing different 

15 operations at the provider program 12 than at the consumer program 22. An example of such a 
method is the SendAck method discussed abover Like any communications object.metho.d, data 
. exchange methods can also call other methods^ including other data exchange methods. In this 
way a succession- of automated data:exchanges may take:place between a provider program ! 2 
and consumer program 22 without any human intervention if none is required. Such automated 

20 data exchanges may also occur between the provider program 12 or consumer program 22 and 
other data servers as explained in the discussion of data query control above and the sections on 
service object partner servers below. This includes requesting data from the server or posting 
data to the server. 

As explained above, when the provider program 1 2 and consumer program 22 are 
25 combined, the same facilities for processing communications objects on behalf of the consumer 
are available for processing message objects on behalf of the provider. For example, message 
objects 1 1 O can contain or produce message elements (211, FIG. 4) for mclusion in a notification 
report (630, FIG. 1 3). Because notification reports are produced by queries against the^databases 
11,21, these message elements can be sorted by any criteria desired by the provider. For 
30 example, they can be sortisd by their parent communications object (110. FIG. 3), by related 
notification element (201, FIG, 4), by the type of attion required by the provider, or by any other 
element contained in the message object which produced them. Within the notification report. 
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message elements can be hyperiinked to other data exchange methods to control fiirtiier 
processing of the message object data. As with data exchange methods in the consumer program 
22, this can include the generation of input forais for gathering additional input from the provider 
and the generation of message objects that.cah be returned to the consumer or to other data 
;;5 servers. 

An example of the fiill cycle of automated data exchange and message object processing 

'f would be the use of a communications object system to provide technical support for a software 
product This is illustrated in FIG. 25. The cornpahy producing the software product 1101 would 
use the prbvider program 12 create a communibatiohs object 35 representing the product The 
10 company would then distribute this communications object 35 to the consumers usirig the 
product (step 1 103). This could occur in many ways, for example by delivering it with the 
product^ shipping it separately on a floppy disk or CD-ROM, e-mailing it to the consumers, or 
making it available on the company's web server. Whenn a consumer using the product had a 
teclmical support question, the consumer could manually locate tttt compan/s communications 
15 object 35 within the consumer program 22. Alternatively the company could add an API call 
directly from the software product 1 101 to the communications object 35 in the consumer 
program 22. Such an API call could be made from commands placed in the software products 
Help menu or product help screens 1 102. By activatmg such a command, the customer can 
automatically call the appropriate page (142, FIG. 3) of the commimications object 35 in the 
20 consumer program 22 (step 1 1 05). API calls are fiirther described below. 

Whether called up manually by the consumer or automatically by an API call, the 
appropriate" page (142, FIG. 3) within the communications object 35 would display the various 
technical support options offered by the company (step 1110). FIG. 26 is an illustration of how 
such a page might typically appear. Each data exchange element 1 43 representing a support 

.25 option appears as a hyperiink command or button. When activated by the consumer, this 

command calls the data exchange method 141 associated with the data exchange element 143. 
The data exchange method 141 then generates an input form for gathering additional data from 

^ the consumer (step 1111): FIG. 27 illustrates how such an input form might typically appear. As 
described above, an input form can display fields for manual input from the consumer which are 

;^30 attributes of a data exchange element. These include checkboxes; radio buttons, drop-down lists, 
and text input fields. Text input fields can be used for free-form text input such as writing 
technical support questions in a maimer similar to writing e-mail messages. The input form can 
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also display data already present as elements in the consumer databaise 21 for confirmation and 
authorization by theconsumer. When the consumer submits the inpiit fotm, the data exchange 
method 141 processes the form input in the same manner that system methods process program 
form ii^ut as described above (step 11 12). This includes any error detection routines, which may 
5 display additional messages or input forms. Once the form data is validated, the data exchange 
method 141 produces a message object instance 1115. This message object instance may include 
mtemally or as attachments any of the. different types of exchange data discussed in this section. 
For example, it could include system data such as the time and day, computer type, CPU type, 
and RAM available. It could also include file data such as the consumer's AUTOEXEC.BAT or 

10 the initialization file for the supported software program 1 102. It could also include data from a 
data query such as a error log report produced via an API call to the supported software program 
1 1 02. The automated inclusion of this data not only saves a great deal of manual effort on the^ 
part of the consumer, but climates manual data entry or attachment errors. Finally, the data ' 
exchange method 141 transmits the message object instance 1 1 IS to the provider program 12 

15 (step 1117). 

At the i»x>vider program 12, the message object instance 1 1 15 executes.a dataiexchange 
receipt method .141 (step 1120). This data exchange.method 141 could be.a polymorphic version 
of the same, data .exchange method; 14.1 used in the consumer program 22j or.a.separate;data..r: 
exchange method 141 . The data exchange method 141 processes the data contained in the - 

20 message object instance 1 1 1 S. Because this data is of known data types in a structured 

transmission format, die data exchange method can apply the provider's own rules 140 or other 
processing logic to automate message processing to the greatest extent possible. This includes 
doing an automated scan of the consumer's input data and included system data, file data, or the 
results of data queries to spot the symptoms of known bugs in the software program 1 101 or of 

25 common operator errors. Based on the results of this processing, the provider program 1 2 can 
produce an message element instance (211, FIG, 4) associated with a particular notification 
element instance (201, FIG. 4) which the provider has classified for techical support requests 
matching this profile (step 1121). This classification can be. based on any data contained in the 
message object 1.1 1 5. This could include the version and platform of the software product 1 101 

30 used by the consimier, the ongmsd techiiical. support option chosen by the coii^^ . . 

probable diagnosis produced by the data exchange method processmg, the number of .technical 
support inessages received from the consumer, and so forth. The headlines from these message 
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element instances (201, FIG. 4) can then be displiqred in a notification report (step ! 122) similar 
to that used for consumer notification (see FIG. 24). In this way notification control can be 
combined with data exchange control to give the providCT a powerfiil medianism for filtering and 
categorizing technical stippgrt reqiiests. 
, 5 When Ae ja-ovider activates a headline link on the notification report, this calls the 

associated data exchange method which produces an input fprm allowing the provider to respond 
^ to the consumer (step 1 123). Similar to the input form presented to the consumer in step U 11 , 
this input form can contain pre-configured response options from which the provider can dioose. 
As with consumer messages, these response options can include botii internal and external data 
:io and attachments. For ejwmple. tiie provider could choose fi'om a list of standard answers to 
frequently-asked questions tiiat would automaticaUy be incorporated in the provider's reply 
- message object The provider could also choose from a list of technical support documents 
related to tiie consumer's symptoms tiiat could be automatically attached to tiie provider's reply. 
Once the provider submits the input form, the process is a mirror of Ae steps tiiat took place at 
15 tiie consumer program 22. First, tiie form data is vaUdated and processed (step 1 124), and tiieh 
anotiier message object instance 1 125 is produced. In order to maintain tiie continuity of tiie 
"tiircad" of messages passmg bade and forth between tiie provider and consumer, tius message 
object 1 125 uses tiie saine system ID as tiie original message object 1 1 1 5. but updates tiie version 
value. This updated message object is transmitted back to tiie consumer program 22 (step 1 1 27). 
20 At tius point tiie stqjs mirror tiie processing tiiat took place at tiie provider program 1 2. 

First, tiie message object instance 1 125 executes a data exchange receipt metiiod 141 (step 1 130). 
The data exchange metiiod produces a message element instance (211, FIG. 4) associated with 
tiie notification element instance (201 , FIG. 4) which tiie consumer designated for this type of 
response (step 1 1 3 1 ). The headline from tius message element instance will now appear on the 
25 consumer's notification report as described above in tfie discussion of notification control. When 
tiie consumer activates tiie message element's headline link, tiie data exchange metiiod 141 
associated witii tiie message element instance (211, FIG. 4) produces an input form, and tiie cycle 
begins again at step 1 1 1 1 . This input form can display tiie provider's response as well as tiie 
; consumer's new reply options. For example, if tiic provider suggests a solution, but tiie consumer 
30 finds tiie solution does not work, tiie consumer can use tiie fontito send tius input back to tiie 
provider. Again, to maintain tiie continuity of tiie messaging tiuead between tiie consumer and 
provider, each message object 1 1 15, 1 125 produced uses tiie same system ID, but updates tiie 
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versibh value. By aithiving inessage objects 1 1 15; 1 125; the data exchange methods at both the 
consumer program 22 arid provider pro^ranl 12 can automatically interlink new messages with 
older versions^ allowing both the provider arid consumer to easily refer to pre^ous messages in 
the thread. Conununications object archiving is further discussed below. ^ * 
5 Data exchange control can also be combined 'with recdpt and ackhbwl^^ control. 

For example, at any stage of message object exchange in the preceding example, the riiessage 
object's receipt method could automatically produce an acknowledgment message object that 
would be immediately transniitted back to the originating program 12, 22. As explained in the 
discussion of receipt cdntiol above; this addio^edgment message could produce an explicit 
10 notification of receipt, or simply disable a scheduled event that would otherwise notify the 
consumer if an acknowledgment was not received within the expected interval. 

Referring to FIG. 3, the preceeding discussion of data exchange has focused primarily on 
data exchange events initiated either manually by the consumer or automatically by schediiled 
events 1 1 7. Eitiier one of these techniques can be employed to either pull new data to the 
15 consiuner or push data from the consumer, to the provider. However data exchange events can 
also be triggered automatically-by data exchange rulesvl:40. Perhaps the most common example . . 
is thie update association rule discussed above. The update association rule (FIG. 1 OB) ensures 
that changes made within the provider database 11 are distributed to all associated recipients 120 
via all associated communications objects 1 10. When the provider and consumer programs 12, 
20 22 and databases 11,21 are combined, a corresponding data exchange rule 1 40 can be employed 
by a consumer communications object 1 1 0 to monitor changes to one or more provider elements 
143, Such a data exchange rule creates an association between an element 143, a 
communications object 1 10, and a data exchange method 141. When the version value of the 
element 143 changes; the rule 140 is invoked which calls the data exchange method 141 of the 
25 communications object 1 10. The data exchange method 141 can then produce a message object 
1 10 to transmit the changed data back to the provider program 12. Alternatively, a message 
object or anotiier type of structured message can be transmitted via any available 
conununications network to any other address the provider designates. In this fashion a ' 
communications object consumer who is also a provider can automatically update all of hisAier 
30 communications object reilatiomhips associatied with a particular element 143 just by editing die 
element 143. A common universal example is change-of-address notifications. With any other 
communications object network, such as postal systems, telephone systems, fax systems, or e- 
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mail systems, a change of addrejss involves significam hiunan labor on the part of the party 
whose.#lR!S!s is changing to noUly, all hi^ 

wnununicatjpm partner must update their o^ynxecords when ? change-of.address notification is 
received, Wh^n <iata exchange rules 14p^ employed in the present invenUon, every 
I communications partnw- is updated ajitpatically >vheM^^^ data 
... elements, change. This includes both, partners who are recipients 120 of the usei^s own 
^ cpmmunicaUpns objects 110, as wega§pa^^ 

communipatioi^ object 1 10 employing data exchange rules. As the number of users of a- 

communications object system grows, the overall hmnan labor savings involved in t^ 
10 two-way updating of contact data can become very significant 

A specific application of data exchange rules is registration updates, discussed in the 
update control section . above. A registration update is a message object returned by a consumer 
program 22 to a provider program 12 or distribudon server 32 in order to modify a recipient 
instance 120 and/or other elements associated with a communications object 1 10. Typically any 
15 element 143 in the con^er database 21 that is part of the registration data maintained in the 
provider database 1 1 wUl be monitored by a data exchange rule 1 40 contained by the 
communications object 1 10. Any changes to these elements 143 will result in a message object 
being produced that produces an update in the corresponding recipient instance 120 or other 
element 143 in the provider database 1 1 . 

Another example of data exchange rules is version monitoring. Version monitoring can 
be a more efScient updatmg technique when the message object traffic volume produced^ 
communications object 1 10 is more frequent than changes to the communications object 110 
itself. With ven>ion monitoring, changestoacommunications object nOare neither e^^^^ 
pushed by the provider program 12 nor regularly pulled by the consumer program 22. Instead 
25.^ message object passed between the programs 12, 22 contains the most recent version 
of the parent communications object 110. A version monitoring mle 140 operatmg in either or 
both programs 12, 22 compares this version value in the message object with the current version 
^. of the communications object 1 10. Whenever a change is detected, the version monitoring rule 
140 executes the update method 141 of the communications object 1 10 to update the currem 
30.^,. version in the consumer database 21. A specific example of version;monitoring is shown in FIG. 
37, explained in the payment service object section below. Version monitoring rules 141 can also 
be nnplemented at distribution servers 32 to.add efficiency to the update polUng process: This is 
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discussed further in the data anliiiahg^^^ 

Becm]se date exchanie coiibo 
be applied in many unique ways. Ah exarhple is offline viewiig of World Wide Web content; 
Existing sbftwafe pfbgrains s^^^ as Freeloiadef from Individual Inc. and WebEx from travelling 

5 Software Corporaiibh dlow Internet users to dowSload tb their local hard disk selected Web 
pages togethCT with all or a selected subsfct of the ifielper files (graphic files, sound files, 
muhimedia files, etc.) iised on thit pag6. these programs are called "offline browsers" because 
they dlow ti»e reader to View all or a tnajbrity of the #eb page's content while offline. This 
speeds tq> viewing tinies end tedtiices diilih^ access diarges. the^ programs can also monitor the 

10 web page using a polling interval set by the usw and download new versions whert tfie page is 
tipdated; 

This iuhctionali^ can be sigiuficaiitly unproved iqjon using a conununicatiohs object 
system and data exchange controls. First, in existing offline teowsers, a user must select specific 
web pages for monhoring and downloading, and there is no sdective notification about changes 
IS to those pages; mh a coinmunieations object system, a single conunimications object 

allow the consumer to-select fiom a variety of notification elements (201i FIG. 4), each vn± its 
own notification control. Second, most existing offline browsers require the user to choose the 
"depth" of linked pages and helper files that will be downloaded for new or changed pages. .This 
is strictly a guessing game for users, who have no clear idea what additional p^es or supporting 
20 helper files they may be interested in. With a communications object system, the pn>vider of the 
content can create a data exchange method 141 that presents the relevant downloading options to 
the consumer, and then intelligently sets a polling interval and selects the content the provider 
knows is related to the consumers expressed interest. Third, with oflQine browsers, downloaded 
web pages have no feedback component other than hyperlinks contained on these pages. With a 
25 communications object system, the downloaded data can include or be linked to communications 
objects 11 0 and their components. Thus feedback can happen both manually using data exchange 
elemente 143 that return message objects 1 10, and automatically using reporting control. 
Reporting control is further discussed below; 

A secbhd application is personalization of web or hypermedia content, i.e., presenting a 
30 customized or filtered view of a web site to reduce the need for scanning or browsing by the 
consumer. One existing approach is to have consumers establish an ID, choose a password, and 
enter personal preference data into input forais provided by the web server. This data is then 
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stored at the web server or aopther remote location and used to present customized views of the 
web ate. An example is MyYahoo from .Yahoo Inc. To see new content, the consumer must then 
manually visit the web site, enter the necessary ID and password, and browse their customized 
conteni^ which is only available online. Whraever the consumer's preference data changes, the 

,3' consumer must manually change it on all such web sites. 

A communications object system overcomes all of these disadvantages. Using a 

^ communications object llOemployingdataexchangemethods 141 to control the relationship, 
the provider can first gather most or all of the consumer's preference data automatically. This can 
be controlled by rules 140 imposed by the consumer. The provider's cominunications object 1 10 

10 itself can create the necessary ID for the consumer using the system ID (100, FIG. 3>of the 
anisumer database 21 or a derivative thereof The consumw is not required to give a password 
manually because the prbvidw's communicatiOTs object 1 10 can communications with the 
consumer program 22 to establish the consumer's identity (the consumer's own indentification 
and preference elements 143 stay safely within the consumers own coniputing environment). The 

15 pt)vider's communications object is able to automatically download and selectively notify the 
consumer of new personalized content as described above. Finally, any changes to identification 
or preference elements 143 are made once locally and are transmitted automatically to all such 
web provider relationships. 

Another approach to web content customization is conrunonly referred to as "cookies". A 
20 cookie is a data structure passed from a web server to a browser as part of the HTTP protocol 
Cookies are produced by the web server and stored locally in a preferences file by the browser; ' 
When the user next connects to the web server with the browseri the web server can interrogate 
the browser for the cookie and use it to identify the user. TTie cookie can additionally store 
preference data about the user, whether entered manually by the user via HTML forms or 
25 collected automatically by the web server based on the user's browsing choices. Cookies are an 
attempt to surmount the manual data entry and maintenance requirements of the first approach 
above. Unfortunately, cookies arc not direcdy viewable or editable by the consumer, nor do 
cookies give the consumer any control over the data collected or transmitted by the cookie. 
:; (Some browsers do give consmners the abilify to turn off the cookie function altogether.) 

30 A conwnunicatidns object system overcomes these limitations by replacing the cookie 

with a communications object 1 10 from the provider. In fact such an improvement can be made 
under the existing HTTP protocol if a communications object exchange is initiated manually by 
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die cdhsumer during a browsing session by clicking on a hypciiihk representing a 
coimnimidations object 1 1 0 on a web page presentad by the web server, fiic resulting do>vnload 
of a communications object 1 10 can triggiet a data exchange receipt method 141 which 
automatically transmits back to the web sen/cr any necesiary data elements 1 43 from the 
5 consumer database 21 . This can be controlled by rules 1 40:iniposed by thfe consumer. The web - 
server can then prepiare and retiffh custonlized content for the consumer program 22 to display to 
die browser. Alternatively, the web server can return another communications object 1 1 O to . 
repeat the infomiation interchange process. In contrast to cookies, the consiimer can be 
completely in control of this process. The consumer can view the elements 143 of the relevant 
10 communications object; edit those elements 143 which involve consumer preferences; and apply 
rules 140 governing data access, data security, and data logging by the conuhunications object. 
These improvonents can bring rich* automated new forms of web content personalization with 
none of the disadvantages of cookies. 

Another approach is to have personalized content delivered autoxnatically to the 
15 consumer via a content delivery application. An example of tfiis solution is PointCast fix>m 

PointCast Inc;.Here the personalization options are storediocally as^part of the i?)plication,:so.the 
consumer effort requircd by the server-based solution above is avoided. However the 
cUsadvantage.to this solution is diat the preferences arc part of a single-application, or. at best part 
of a limited number of modules vwthin the application: Thus,.it is not possible for a large number 
20 of providers at multiple locations to offer content personalization options. Notification options 
are determined at the application level, not the provider level or content level, so a user's choice 
of notification options is very limited. The personalization options are for the reception of 
information only. They do not extend to feedback or data exchange automation. 

A communications object system overcomes these limitations by allowing providers and 
25 users to control communications relationships at the level of individual communications objects 
1 10. Any number of providers and consumers can take part, each with access to the full range of 
data exchange control provided by communications objects 1 10 and data exchange methods 141 . 
Thus a communications object system can be used to provide any number of of personalized 
content delivery services, rather than the limited number offered by one particular application. 
30 For example, data query control can be used to submit an HTTP request to any web server. This 
query request can include a unique identifier for the consumer such as the consumer's UID or a 
derivative thereof. This query can also include any new or updated data elements 143 in . 
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cansumer database Zl that pertain to the provider and are not already present or current at the 
web. server. The elements. 143 or communications objects 1 10 returned by this query can offer 
conqjietely customized news reports, weather reports, product brochures, advertisements, stock 
quotes, real estate lisUogs, classified listings, Internet searches, health care advice, or any other 
5 current persoiialized information desired by the consumer. The specific data type is not a limiting 
feature of the invention. The coiisumer can also control notification options for this information 
down to the level of elements 143 . The information can also be hyperlinked to data exchange 
elements 143 within the relevant communications object for direct, automated feedback by the 
consumer. 

10 Communications nhi<»rt Pyy hf^ge rinntml 

A special case of data exchange control is communications object exchange control. This 
are the functions by which communications objects 1 1 0 can control the retrei val and transmittal 
of other communications objects 1 1 0. The retreival of one or more communications objects 1 1 0 
by another communications object 1 1 0 is known as link control. Link control can be provided 

15 using link elements 143, link methods 141, and link rules 140. Collectively these are refened to 
as link control components. For ease of sharing between conuminications objects 1 1 0, link 
control components can be combined in a separate component object type (8 12, FIG. 1 7) called a 
link component object 1 10. In a communications object system, the fimction of link component 
objects 1 10 is directly analogous to the fimction of hypertext document retrieval protocols in 

20 hypertext systems. The best example is the usage of URLs (Uniform Resource Locators) in the 
World Wide Web. In their simplest form, link elements 143 can in fact be URLs, in which case 
no link method 14 1 is required if a web browser is used as the display interface. However the 
architecture of a communicaHons object system permits much more powerful forms of link 
control than URLs. 

25 The first advantage is the use of link methods 141. URLs are a standardized addressing 

protocol for the retrieval of hypertext files, binary files, and other digital resources used 
anywhere on the web. The URL protocol, when combined with the HTML encoding/display 
protocol and the HTTP commuhicaUons protocol, forms the standards that make the web 
possible. AU web programs must incorporate this protocol in order to operate. Introducing other 

30 addressing protocols would require an enormous reehgineering and upgrading effort throughout 
the web. With a communications object system, the URL protocol is just one possible link 
method 141. Other link methods could employ other protocols, syntaxes, name resolution 
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services, and features. Since those methods <an be made available via any of the mechanisms 
described in the discussion of methods above, htv^ link mettods 141 can easily be propagated 
throughout a communications object system. 

A second advairit^e is multiplicity. A URL can only represent a single resource on the 
5 web, although the browser receiving thai resource can be programmed to retrei ve additibhal ' 
resources, such ias the gr£4>hi6s associated widi an HTML page, automatically. A lixik element 
143 i on the other hand, can designate any number of resources to be retrei ved in one action. It 
can supply theise resources through its own attributes, through other associated elements, or 
through link methods 141. 
10 A third advantage is processing flexibility. The processing of the resource received by a 

URL reqiiest is determined by the browser or other program executmg the URL request This 
processmg can ony be modified by changing the protocol or reprogramming the receiving 
software. With a communications object system, a link method 141 also controls the processing 
of the resource retrieved. The link method 141 can also call o^ methods for processing the 
IS resource retreived. If the resource is a communications object 1 1 0, its own receipt method or 
methods 141 can further determine, the processing itreceives. 

A fourth advantage is the power of the address resolution protocol. As explained in JhSi 
World Wide Weh Unleashed: cited above, a URL is resolved by a web program in several steps. 
First the IP (Internet Protocol) address of the host computer is resolved via a lookup via a lookup 
20 to the user's local DNS (Domain Name Service) host. This host may in turn lookup the name on 
additional DNS hosts until the name is resolved successfully or an error message is produced. 
Next the web program requests the specific HTTP resource on the IP host specified by the URL. 
This can be the name of any document or MIME file supported by the web protocols, or it can be 
the name of a method available on the host together with the parameters to pass to that method. 
25 In the latter fastion, it is possible for the host tp "resolve" a first URL into a second URL by 
returning the second URL in the form of an HTTP redirect command as the result of its 
processing. An HTTP redirect is a URL that is automatically processed by the web software that 
made the original URL request In this manner a succession of redirects is possible unidl the final 
resource is resolved. The use of HTTP redirects to accomplish the persistent naming of web 
30 resources is generally discussed in Stuart L. Weibel and Erik Jul, "PURLs to Improve Access to 
Internet*' in the 1995 Nbvember/December issue nf th^ Online Computing Library Center 
(QCLC^ Newsletter, page 1 9. Information on the PURL naming service is also available on the 
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World Wide Web at htft);//p^^l.Qplc.o 

This approach r^uires that all address resolution logic be present in one of two places: in 
the DNS protocol, or in the address resolution methods available at remote hosts. With a 
conrniunications object system, the address resolution logic first resides in the link method 141, 
5 which can in turn call any other communications object method. 1 4 1 or partner server method 
141 as described in the section on communications object methods above. This means that by 
. , using a UID, URL, name, or other attribute or combination of attributes supplied in a link 

element 143, the link method 141 can first search the local databases 1 1, 21 within the programs 
12, 22 for the specified communications object or objects. If the communications object is not 
10 found locally, the link method 141 can then query one or more distribution servers 32 where the 
communications object is likely to be stored, such as LAN or WAN distribution servers. These 
distribution servers 32 may be represented by distribution service objects 1310^ which will be 
further discussed below. If the target communications object 1 1 0 is not found on a distribution 
server 32, then the link method 141 can process the attributes of the link elements 143 to 
15 determine the next most efficient means of retreiving die communications object For example, if 
a URL is available, the link method 141 could process this. If a URL is not present but a UID is 
available, the link method 141 could automatically use a UID resolution service. If a UID is not 
present but a name is available, the link method 141 can use a name resolution service. UID or 
name resolution services can operate similarly to the Domain Naming Service (DNS) for the 
20 Internet, or to the PURL naming service cited above. Additionally, die name resolution service 
could incorporate features under consideration by the Worid Wide Web Consortium (W3C) for 
Unifomi Resource Identifiers (URIs) and Uniform Resource Name (URNs), These systems are 

discussed generally by tiieW3Cstaffat the W3C World Wide Web site at . 
htq)://www.w3.org/pub/WWW/Addressing/. 

25 A communications object system offers particular advantages for deploying a global 

name resolution service. With such a service, each communications object provider would have 
the opportunity to obtain a unique name corresponding to the UID for any communications 
object 1 1 0. This naming service would operate in tiie same manner as DNS, where Intemei users 
can curremly apply for a unique domain name corresponding to a unique Internet host IP address. * 

30 Just as DNS allows any web program to resolve a domain name in;a URL to a unique host IP 
address, a global communications object name service would allow any link metiiod 141 to 
resolve a communications object name to its UID, URL, or any otiier unique addressable 
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attribiites. Because this name Fesolution service is comptetely abstracted firom athy underlying 
communications addressing protocol, it would allow the use of names that a^e exactly the same 
as the real-world name of the person, company, product, seridce, or other entity that the 
commimications object represents. Also, because the name service results are processed by a link 
5 method 141, the link meth<^ 141 can determine the most efficient way to retreive the specified 
communications object 1 1 0. Such a iiame servi6e can be made available to other 
communications objects 1 10 by use of a name service object 1310. The use of name service 
objects and name partner servers will be further discussed below. 

When the provider program 1 2 and consumer program 22 are combined, a 
10 commimications object system can also automate the exchange of commimications objects 1 10 
between two providers. This is a comihon need analogous to the exchange of biisiness cards 

between individuals. Although only one business card need be exchanged to create a 

communications relationship, a two-way exchange pro>ddes the greatest number of 
conmiunications options in both directions. This synchronization can be accomplished by the use 
15 of a special method 141 called an autoexchange method. An autoexchange method 141 operates 
as both a receipt methodrl41 and a data-cxchangemethod Ml The the data structures involved 
aie illustrated in FIG: 3. When a provider program 12 first receives a conmiunications object 1 10 
wth anautoexchangeTOethod'Ml; itiirst.compa^ ID:of the 

conmiimications object 1 10 with those of its recipient instances 120: If the database system ID is 
20 already present, the relationship is aheady established, and the autoexchange method is igriored. 
If not, the autoexchange method 141 is executed according to the receiving provider's 
preferences. Such preiferences can be specified using the provider preferences form (3 1 6, FIG. 9) 
and stored in the global preferences instance 103, One preference may be to automatically 
generate and transmit a default communications object 110 instance back to the first provider, 
25 Another.preference may be to generate a message element (211, FIG. 4) for use with the 

notification report (630, FIG. 13) to notify the receiving provider of the autoexchange request. 
The headUne of the message element (21 1, FIG. 4) could be linked to the create new recipient 
form (311, FIG, 9). This form would serve as the input form for the autoexchange method 141 . 
The received cominuiiications object 1 1 0 could supply the attributes necessary for the recipient 
30 instance 120 on this form. Therefore the receiving provider need only select the preferences for 
the communications object or objects 1 10 to be returned to the first provider. When this form is 
submitted, the autoexchange method will trigger the distribution of this conununications object 
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as described above. 

The autoexchange of communications objects 1 10 can also be exteiided to web servers, 
data servers, and other electronic communications relationships. This iis an extension of the 
process of using communications objects as "cookies" described in the prece^ng section on 
data exchange control. 

Forwarding and Chaininp Cnntrn] 

A special case of communications object exchange is v*eii a coiisumer wishes to send a 
provider's communications object in the consumei's database 21 to anotho- consumer. This is the 
real-worid equivalent of a businesssperson needing to share the contact infonnadbn for ft 
customct with a business iissociate, or a inail order customer wanting to tell a fri«id ho\v to 
' subscribe to a mail order catalog. A communications object system can acconyilish this using 
forwarding methods. A forwarding mediod 141 allows the user of one consumer program 22 to 
transmit another provider's communications object via the push technique to anoAer consumer 
program 22; 

15 Execution of a forwarding method typically displays the forward form (63 5, FIG. 13). 

The forward form allows the user to manually input the e-mail address, encoding data, and any 
other data necessary to forward the communications object 11 0 to the recipient. Alternatively, 
the user can select the recipient from a list of recipients (120, FIG. 3) already present in the 
consumer database 21 . In this case, the recipient instance (120, FIG. 3) contains the necessary 

20 information to address, encode, and transmit the communications object. When this form is 
submitted, the forwarding method generates a message object 1 1 0 and transmits it to the 
recipient. The contents of this message object can vary with the type of forwaitiing desired. An 
anonymous forwarding or "redirect" operation would simply send the communications object 
110 itself, exactly as if it had been pushed Srom the original provider. TWs communications 

25 object would be received at the recipient's consumw program 22 just like any other 

commmiications object 110. A signed forwarding operation would include a forwarding element 
. 143. A forwarding element is a recipient instance 120 representing to the forwarding consymer, 

e.g. fteir system ID, name, e-mail address, and so on. This information could be displayed by the 
. notification method at the receiving consumer program 22. A signed forwarding operation could 

30 also include a message element (211, FIG. 4). In this case the forwarding consumer could control 
the headUne and message displayed by Uie notification metfiod at the receiving consumer 
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program 22. A signed forwarding operation could also include copies of the forwarding • 
consimiers element preference instances (147; FIG; 3)/Ili this case the ieceiving consumer would 
be able to choose whether to adopt these preferences or start with the default preferences of the 
original communications object 1 10. Any of these forwarding operations could also be - 

5 authenticated, which would add an element 143 with a digital signature Verifying theldentity of " 
the forwarder. Authentication is described in the encoding control section above, and 
authentication service objects are further described below. 

Alternatively, the forwarding operation also need not include the original 
communications olgect 1 1 0. The forwarding message object 1 1 0 can instead include a data 

10 exchange element supplying the attributes of the conununicatiohs object 1 1 0 and a daita exchange 
method for retreiving it Such data exchange method can operate automatically as a receipt 
method or can present an input form for manual confirmation by the consumer. If the 
conomunications object 1 1 0 is distributed via the pull technique, the data exdiange method can 
mreive it from the distribution server 32. If the cotrimuhications object 1 10 is distributed via Ae 

15 push technique, the data exchange method can send a message object 1 1 0 to the ori^iiating 
provider program 1 2 requesting transmission.of:the conununications.dbject :1 10; Such message 
object can be . processed automatically by the provider program 12 or require manual approval by 
the provider,.depending on.the rules 140 i^lied.by the provider to communications object v 
transmission requests. 

20 Forwarding is a unique operation in that update control can be specified by the 

forwarding and/or receiving consumer. By default, the forwarded communications object will 
use the update control sproified by the original provider. However, subject to forwarding control 
rules (discussed below), thel forwarding consumer can also control updating. This is 
accomplished by including in the forvsrarding message object 110 a receipt method governing 

25 iqKlating, This receipt method can designate that the communications object 1 1 0 will be updated 
via the push technique from the forwarding consumer program 22 or another consumer program 
22, or updated via the pull techniqxie from a disoibution server 32 other than the origmal 
distribution server 32, This can be dorie regardless of how the conununications object 1 10 is 
updated at the originating consumer program 22. The ability of a communications object to be 

30 updated from anotiier consumer program 22 or distribution server 32 is referred to as chaining. 
Chaming is a powerful means of distributing communications object updates, because it spreads 
the load for distributiiig objects tim)ughout die communications network 3. This makes the push 
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methpti tnorei feasible for large-scale distribution of coimniinications objects. A particular 

example of chaining is the distribution of communications objects on a local area network 

(LAN), If onp consume^ jawgram 22 or distribution server 32 on the LAN is receiving 

comiiiumwttions object updates from over a publip data networic sudi as the Internet, this 

5 prolan) cm autonaatically distribute updates to other^coiisumers onthe LAN. This can 

significfflitly lower traffic on the public dat^networic and increase the efficiency of the 
commtmications object distribution process. 

Chaining can be implemented via push or pull techniques. Chaining via the push 
technique is accomplished in the consumer program 22 by use of a consumer receipt method 1 4 1 
10. that invokes a forwarding rule 140. A forwarding rule associates a communications object 
., instance 1 10 with one or more recipients 120. When ah update to a communications object 1 10 is 
received by the consumer prognun 22, the receipt method checks to see if it is subject to a 
forwarding rule. If so, a copy of the communications object 1 10 is transmitted to the recipient 
120. Chaining ofifers the same update control options as described in the update control section 
15 above. TTus means it can be controlled by the forwarding consumeri or the forwarding consumer 
can pass control to the receiving consumer. When the pu^ technique is used, message objects 
1 10 can be used to control the creation and modification of recipient instances (120, FIG. 3) and 
acknowledgment instances (121, FIG. 3) in the forwaiding consumer program 22 in the same 
way as they are in the provider program 1 2, described above in the update control section. 
20 The original provider of a communications object 1 1 0 can also confrol forwarding and 

chaining pertaining to the object This is necessary because communications objects may contain 
sensitive data or methods which the provider does not wish other consumers to obtain without 
the provider's control. As shown in FIG. 3, this can be accomplished through the use of 
forwarding conttol attributes of the communications object itself 1 10, forwarding control 
25 . elements 143, and forwarding control rules 140. As with other rules, forwarding control rules 
may be implemented at the system level, or they may be implemented by a particular 
communications object. In case of conflicts, the more restrictive forwarding control rule takes 
precedence. Forwarding control rules can cover all aspects of forwaiding and chaining 
operations; Specifically, they can prohibit any forwarding, permit forwarding but prohibit 
30 . , chaining, permit chaining only using specified update techniques; pemiit forwarding without the 
inclusion of element preference instances 147, and pemjit forwarding or chaining only with 
notification to the original provider. Notification to the original provider can be accomplished by 
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having.the forwarding methdd^tFansBiit a message dbject l 10 back to the original provider ' 
>^42enever a forwarding event tiakes plaice: These messages objects can be used to track recipients 
in the same.&shion as described above in the receipt and acknowledgmmt coiitrol section: 
Forwarding control rules cain also control the "depth" of chaining. This can be accomplished by 

5 incrementing an integer coxmter attribute ofaforwarding control element 143 each tithe a 
communications object 1 10 is advanced to aiibdier consunlei prograrn 22 in the chaiin. If the 
maximum chain depth is exceeded, further chaining is not allowed. A forwaiding method can 
track the consumer programs 22 that comprise the chain by including the fcnvnarding elements 
1 43 for each forwarding consumer in the communications object 1 1 0. A receipt method 1 4 1 can 

10 optionally generate an input foiin whereby the receiving consumer can choose to receive updates ' 
from any consumer program 22 higher m the chain. A fonvarding control method can also use an 
input form to have forwarding control rules ^lied manually by the forwarding consumer. Such 
an input fomi can include reminders about sensitive data and display rules about forwarding or 
chainmg for the consumer to follow manually. Distribution control can allow the original 

15 provider to selectively sq^ply fonvarding rules to specific consumers. This is done by- producing 
custom forwarding^controlattributesdlO, elements 143,.or:nile^ . 
Distribution.contipi procedures are described above in the distribution control section. ■■■ 

Transfer Control 

A forwarding operation creates a copy of a communications object 110 at a second 
20 consumer program 22« leaving the first communications object 110 at the first consumer program 
22 intact This creates a new communications relationship between the new consumer and the 
original provider. By contrast, a transfer operation moves a communications object 100 from one 
consumer program 22 to another consumer program 22, and does not leave a copy of the - 
communications object 1 1 0 at the fu-st consumer program 22. Thus, a transfer operation does not 
25 create any hew communications relationships, but instead transfers ownership of a 

communications relationslup from one consumer to another. This is similar to the difference 
between copying or moving a computer file. The copy operation creates a second physical copy 
in a second location; die move operation keeps only one copy in the new location. 

Methods 141 used to transfer communications objects between consuriiers are referred to 
30 as a transfer methods. Just as a move operation on a computer file is often impleinented by the 
operating ^stem as a copy operation followed by a delete operation on the original file, a 
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coQimunications object transf<;r method may be canied out as a forwarding method followed by 
termination method; In addition, just as most computer operating systems first confirm the 
suipcessfii} of the file to the new location before deleting the fi;ie in the old location, a 
(K^^imuniciatioiis object ^fystem should .preferably allow consumm to confirm the. successfiil 
5 Q^ansferofthe.transfenedcon^ 

coinmunications objj^t fi^m the transfening Qonsumen This can be accomplished by using of 
message objects 11 0 as described ahow in the receipt and ackhowledgmeht control section. 
Specifically, as illustrated by the data structures in FIG, 3, a transfer method 141 generates a 
message object 1 10 to the receiving consumer in the same manner as a forwarding method. The 
10. primary difference is that.the message object includes a transfer receipt method 1 41 that adds a 
transfer rule 140 and an associated scheduled event 11 7 to the receiving consumer's consumer 
database 2 L The transfer mle 140 is associated with the transferred communications object 1 1 0 
such that when an update to the communications object 1 10 is received, the rule 140 is triggered. 
The rule 140 then executes the transfer method 141 which first deletes the associated scheduled 
15 event 1 17. The transfer method 141 then produces a message object 1 10 and transmits it back to 
the transferring consumer program 22. This message object invokes the originating transfer 
method 141 which then deletes the associated communications object 1 10. Optionally, the 
transfer method 141 could also produce a message element (211, FIG. 4) to provide notification 
to the transferring consumer that the transfer is complete. If an update to the communications 
20 object 1 10 in the receiving consumer program 22 is not received before the scheduled event 1 1 7 
is triggered, it means an error condition likely exists. In this case the scheduled event .1 1 7 can 
produce a message element (21 1, FIG. 4) to provide notification to the receiving consumer. The 
scheduled event 117 can also execute the transfer method 141 v4iich produces a message object 
. 110 and transmits it back to the transferring consumer program 22. This message object invokes 
25 . the originating transfer method 141. This transfer method can then either attempt a retrarisfer of 
the conMnunicaiions object 1 1 0, or produce a message element (2 11 , FIG. 4) to provide 
notification to the transfening consumer, or both. The options for automatic error correction are 
more fiilly described in the receipt and acknowledgment control section above. 

As with forwarding control, transfer control can also be exerted by the original provider 
30. using transfer rules 140 and transfer methods . 141 in the communications object 1 10. Transfer 
rules and transfer methods are a particularly powerfiil means of data exchange control. because 
. they can accomplish automatic data exchange events involving the provider, the transferring 
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cdhsumer; and the receiving cdnsnmer- all' in one. An example is the transfer of owiier^hip of a 
real world object, such as aidi automobile. A re^-wofld liile applies to such a transfer, namely that 
the selling consumer must notify fte automobile lic^iig authclrity, and the buying ccAisumer 
must apply for^ new title fix>m the licensing authority. In this case the licensing authority would 

5 be the provider of a commiinicadonis d>bject liO representihg an autoniobile title. The sellings 
consiizher would have obtained the (>o»mmtmidaiti6ns obje^^^ 1 1 0 vAk6h he/she purchased the 
automobile. Using data exchahge methods ais explained above, the licensing authority Avould 
have used the communications object 1 10 to obtain the necessary elements 143 from the 
consumer required by law to register the vehicle. The licorising authority could then use updates 

20 to the communications object 1 10 to communicate with the consumer about the license, such as 
sending notifications about annual license renewals. (Payment for such license renewals can also 
be autoniated by data exchange methods in the communications object 1 10, as further described 
below.) When the time came to transfer the automobile title, the selling constimer would invoke 
the transfer method 141 in the conmnmications object 110. The transfer me^d 141 would first 

IS generate an input form requesting the necessary data idx>utth6 buying consumer a^^ 

details: (Ifa.communications object :1 10 representing the buying constrnio* was also present; an 
association with such object 1 lO.could be used to provide such data.) The transfer method 141 
would then produce two message objects: 1 10. The first message object would be transmitted to 
the licensing authority; containing.the necessary elements 143 to automatically register the sale. 

20 The second message object would be transmitted to the buying consumer. This would include the 
forwarded communications object 110 representing the title. A transfer rule 140 would also 
determine which element pHeference instances 147 must be transferred with the communications 
object .1 1 0. For example, the Vehicle Identification Number (VIN) must be uansferred with the 
title; a new VIN may not be specified by the buyer. The transfer method 141 would also add a 

25 rule 140 to the selling consumer's database 21 requiring that affirmative acknowledgment 
message objects needed to be received from both the licensing authority and the buying 
consumer before the communications object 1 10 representing the title will be deleted. The 
transfer method 1 4 1 could also create a scheduled event 1 1 7 that checked for the receipt of these 
. message objects after a specified interval. 

30 .On the buying consumer's part; the message object : 1 1 0 received with the transferred 

commimicalions object would invoke a transfer method 141. .This transfer method 141 would 
first add a Uansfer rule 140 to monitor updates to the communications object 1 10 to ensure that it 
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>va$Qgeratmg:pit)perly. The timsfCT 141 could also produce a scheduled event 117 

associa!te4. mdi tfae transfer rule: 14Q. This scheduled event 1 1 7 would che&k for.the receipt of a 
reply mess^e objpct from the licensing authority. Next die transfer method 14 1 would produce 
an iQput fonii lequjBsting CQnfiimation of the purchase and application for the new title by the 
5 buying CQnsininer. It is signficant to point out that the buy ing consumer should not need to enter a 
single piece of data other than authentication or confirmation information. All such data is 
aheady present either in the communications object 11 0 or the consumer database 21 . The 
transfer method method 141 would then produce a message object 1 10 to be transmitted to the 
licensing authority with the title application. When the licensing authority returned a 

10 acknowledgment message object 1 10 to the buying consumer, it would trigger the transfer rule 
1 40. The transfer rule 1 40 would execute the transfer method 141. The transfer method 1 4 1 
would first delete the u^fer rule 140 and its associated scheduled event 1 1 7, The transfer 
method 141 would then produce another acknowledgment message object 1 10. to return to the 
selling consumer. When this acknowledgment message object was received^ the same sequence 

15 of events would take place. The transfer rule 140 would execute the transfer method 1 41, vAxich 
would first delete the transfer rule 1 40 and its associated scheduled event 1 1 7. It would then 
delete its associated communications object 1 10 and then delete itself. This would complete the 
transfer, with all parties assured of verified data delivery to the others. 

Transfer control can be applied to almost any situation where the real world ownership of 

20 an object or goods is transferred by an exchange of data between the transferee and the 

transferor, or between the transferee, transferor, and a third party such as a licensing authorit)\ 
broker, agency, listing service, and so on. A universal example is classified ads. By using a * 
communications object instance 1 1 0 to represent goods for sale via a classified advertising 

- v: service, all or most of the communications transactions between the buyer, seller, and classified 

25. . ad service can be automated. The use of a communications object system for classified 
advertising is further discussed in the description of data exchange service objects below. 

Termination Contrnl 

A communications object system also offers an efficient new way for providers and 
consumers to control the termination of communicafions relationships. In most communications 
30 systems, it is easy for a provider to terminate a communications relationship. This is also true of 
a communications object system. As discussed in the distribution control section above, 
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providers can control commumcattons object distribiidon by both push and piill techniques. 
Refezring to FIG; 3, if a irovider controls the distnbu&dn^W^^ a cditunimcatiohs object 1 1 0 via the 
posh technique, the provider need only delete the association of a recipient 120 with a 
conununications object 1 10. If the provider controls the distibution of a communic^ons object 

5 110 via the pull techiaique^ the provider can cha^e the behavior of the distribution control 
ntethod 141 or distribution control rules 140 included in the (^mmimicapdons'bbject 1 lO or 
transmitted to a distribution server 32. 

However, in many commimications systems, it is often very difficult for a consumer to 
terminate a communications relatioxiship. An example is the difiBculty many Consumers have in 

10 being removed from direct mailing lists oi- telephone solicitation lists. Witti the communications 
system of the present invention, consumers have complete and inunediate control over any 
communications object relationship. From the consumer's perspective, this is accomplished 
simply by deleting the corresponding communications object 1 1 0 using the delete object form 
(623, FIG. 13). If a termination method 141 (Fig: 3) is present in the communications object 1 10» 

IS the delete object form calls this method; otherwise, it calls a defauh system termination method 
141. A system termination method^l41 would simply delete the commtmications objectrl 10 from 
the consumer database 21. Optiotially the system termination method 141 can replace the 
association between the communications pbject:! 1.0 and the database.100 within association 
between the conmnmications object. 110 and a special "trash*! fblder. l IS. This permits the user to 

20 change his/her mind and recover the terminated communications object 1 10 at a later date by 
reversing this operation. A similar technique can also be used just to temporarily suspend or 
deactivate a communications object 1 1 0, which could later be reactivated by reversing the* 
operation. 

By including a termination method 141in the communications object 1 10, a provider can 
25 also control the iactions taken upon termination of a conununications relationship. Generally, this 
does not mean the provider can prevent the consumer from terminating the relationship (i.e., 
deleting the communications object). Rather, the provider can control some of the actions taken 
when a communications relationship is temunated. An example is notification. If a 
communications object 1 10 is updated via the push techhique, the provider must be notified in 
30 order to delete the association between the recipient instance 120 and the conununications object 
110. This notification can be processed manually by the provider, or automatically by tiie 
provider program 12. In either case the teiinination metiiod 141 produces a message object 1 10 
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and transmits it back to the pipvidqr program 12. When it is receiVed; a receipt metfiod 141 of 
the message object can delete the association, bety/een the recipient 120 and tbe conutiuhications 
object 1 10. Ahematively, it can first produce a mesisage elanent (21 1, FIG. 4) that notifies the 
provider of this action. When the headUne of the m^sage element (21 1. FIG. 4) is selected, the 
5 teminalionmethod 141 canpioduce.aniiq>utfom 

For cxanvle, tbe provider may wish to replace the association between the lecipient 1 20 and the 
communications object 1 1 0 with another one between the repipieiat 1 20 and a special folder 1 1 5 
such as an "Former Customers" folder. This maintains tiie consumei: information so that the 
provider can atteri^t to reestablish the relationship at some fiiture date. 
19 If a communications object 1 10 is updated via the pull technique, it is not necessary for a 

message object 110 to be returned to the provider program 12. Deletion of the communications 
object 11 0 at the consumer program 22 will terminate the relationship. However, the provider 
may still wish to employ a termination method 141 to receive overt notification of this event 
Furthermore, regardless of the update technique used for the communications object 1 10, the 
15 provider may wish to employ a termination method 141 as a data exchange method. A common 
reason for doing this would be to ask the consumer why he/she is terminating the 
communications relationship. In this case the tetmination method 141 generates an input form 
where the consumer could indicate his/her reasons by selecting from checkboxes, radio buttons, 
or drop-down lists, entering text into a text box, or any other means of data input. When this 
20 inpwfonn is submitted, the tetmination method 141 generates a inessage object 1 10 aiid .. 
transmits it back to the provider program 12. At the provider program.l2 a receipt method can 
automatically compile the consumer's input by storing it as elements 143, inciementing counters 
within eleinents 143, storing it in an external database, or any other data processing method. In 
this fashion the provider could periodically review aggregate statistics and/or direct textual 
25 feedback from consumers about why they terminated the communications relationships. 

In certain cases, a termination method 141 can be combined with termination rules 140 in 
order to control the processing of a termination method 141. An example is the case of a 
communications object 1 10 representing an automobile title given above. Here a termination rule 
140 could specify thai, once initiated with an actual automobile title, a communications object 
30. 1 10 could not be terminated until a some form of acknowledgment message object 1 10 had been • 
received from the licensing authority. This might be a transfer acknowledgment or a destroyed 
vehicle acknowledgment, or any other form of acknowledgment for proper disposition of the 
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titie;= Sucha rule cdidd be very valii^ authority in enforcing compliance with 

the laws coveririg automobile dUe tiegiitmti^^ 

A communications object sy^em provides a unique mechanism for enforcing the 
temiinatidn of a commuriicaliohs rclidonship. In the course of a communications relationship, a 
5 provider may have obtained a consumer's e-niail address. If so, the provider would have the 
ability to send the rahsunier hew cdmmimications objects even after the consumer has already 
terminated the commutu^ktions rBlktiohship. Although the consumer is able to delete these new 
communications objects with a single action, a large number of providers taking this action still 
requires significant effoft and irritation on the part of the consumer. This is essentially the 

10 electronic equivaleht of "juiik niair. To prevent this, the consumer database 21 can track all or 
selected terminated conimunicatiohs objects 1 1 0. Such a record is commonly referred to as a 
"kill file**. This is accomplished using a tenbiination rule 140. First, the termination rule 140 
requires that any termination method 141 executed in tfie consumer program 22 replace the 
association between the communications object 1 10 and the database 1 00 with an association 

15 between the communications object 1 10 and a designated "kill folder" instance 1 IS. The 

termination rule 1 40 may also make this an optional checkbox on any. input form generated by 
the termination method 141. Second, the termination rule 140 is triggered by the receipt of any 
new communications object 1,1 0..The termination rule. 1 40 executes a termination method 1 4 1 
that compares the UID of the new communications object 1 10 with the UlDs of all 

20 communications objects 1 1 0 associated with the kill folder. If there is a match, the termination 
method 141 can take whatever action is specified by the consumer. Typically, this will be to 
delete the communications object 1 10 without notification to the consumer. Alternatively, the 
termination method 141 could compare only the provider ID (the system ID of the provider 
database 100) with the provider ID of all commxmications objects 110 associated with the kill 

25 folder. This would delect any communications object 1 1 0 produced by a particular provider, not 
just a specific communications object 110. Another option is for the termination method 1 4 1 to 
track the number of attempted transmissions for any particular communications object 1 10 by 
incrementing an integer value attribute of tiie association between the conunimications object 
1 10 and the kill folder 1 IS. When this integer value reached a threshold, the temunation method 

30 executes a notification method notifying the consumer, who may then take appropriate action. 

Event Tracking Control 



aNSOQCIO: <W0__ 9732251 Al .1 > 



..^Om/^iSl PGT/US97iflk32os 

-121- 

..yijjUt^'inaiiy other conununicatiQns systonSi a communications, object system, is able to 
provide duect, seamless control over event tracking.. As shoym in FIG. 3, thjB principle data 
stnwai^ involved with event tracl?iog qfiSrtipl, m t^e event class 1 J 6 and..tfie logged event class 
1 18. Any cqmmu^cations obj?cj system methijd may ixoduce a logged event instancy 1 1 g for 
5 purposes of tracking communications actions; 

There are many uses for cpnununications event logs. One of the most common is error 
tracking, System rules 140 can monitor logged event instances 1 18 to provide alerts to frequent 
error conditions. Another common usage is providing communications relationship histories. For 
example, a provider can specify that a data exchange method 141 used for product ordering 
10 create a logged event instance 1 1 8 each time a product is ordered. The provider can have the 
same era related data exchange method 141 make logical decisions within the consumer 
program 22 based on a query of the logged event instances 1 18 for previous piwiuct orders. Such 
data can also be reported in a message object 1 1 0 transmitted to the provider. This can decrease 
data processing requirements on the provider's end and increase the ability of data exchange 
15 methods 141 to make deciaons relevant to the consumer's actual needs. 

Event tracking control is particularly valuable for the generation of reports and statistics 
reports related to the use of particular conununicadons objects, groups of communications 
objects, or the usage of a provider program 12 or consumer program 22 as a whole. Reporting 
control will be further discussed below. 

20 DataAreTiiving^-f^ntf^l 

By functioning as active databases, the provider program 12 and consumer program 22 
can control the archiving of the data they store. This is a very useful capability for many . 
communications functions. First, many providers and consumers frequently wish to refer to past 
communications data. When stored in electronic format, this data is also computer searchable, 

25 which is another key advantage. Additionally, archiving data can be useful for error correction, 
as explained below. As shown in FIG. 3. data archive conm)l is achieved primarily through the 
use of archive attributes, archive rules 140 and archive methods 141. The application of data 
archiving rules 1 40 in both the provider program 12 and consumer program 22 is explained 
above and in steps 735 - 737 of FIG. 15. These examples show how an archiving attribute and 

30 rule are used to control the number of previous versions of a communications object that will be 
archived. Archiving rules also allow control of archiving using time intervals, data size 
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parameters, hy the piresmce.of of dement preferences 147, and other p^iameters. 

It is paiiiCTiIariy iiisiiiffl' f^ both pn>vidOT Md ainsume^^ able to cdritrol archiving at 
both a global database level and a coifuiiimicattidns object level. It can aliso be useful to control 
archiving at the element level. Global archive control is accomplished by storing 

5 conraiunications object archive preferences as attributes of global prefereiices 1 03 and applying 
system archiving rules 140 and system archiving methods 141. Individual communications 
object archive control is achieved by storing archive jireferetic^ as attributes of the 
communications object preferences el^ent 127 and applying ardiive rules 140 arid archive 
methods 14 1 associated with the conmiunications object 110: Element'archive control is 

10 accomplished by storing archive preferences as attributes of die element 1 43 and q)plying 
ardiive rules 140 and archive methods 141 associated with the elmient 143. these three levels 
can also be inteimatched. For example/if a communications object included a archive preference 
attribute in its preference element 127, but had no archive method 141, then the global system 
archive method 141 uses the local archive preference attribute. 

15 Archive control can also maiiitain instances of system objects. This is particularly 

valuable for nwdntainingrthequeue^of logged event 140 can 

specify that any logged event instances 1 17 older than X interval be deleted, preventing an 
unnecessary buildup of data;. 

In general, providers only need to control archiving in the provider database 1 1 and 

20 consumers only need to control archiving in the consumer database 21. However, archiving 
control can also be combined with distribution control and data exchange control as a way to 
ensurel the versions of a communications object in a provider database 1 1 and a consumer 
database 2 1 stay synchronized; This is another aspect of version monitoring, discussed above. 
Version moiutoring is desirable becaiise it is possible for the consumer to miss versions of a 

25 commuiiications object instance 1 10. For example, if the communication^ object instance 1 10 is 
distributed via the push technique, communications network errors may cause the transmission to 
fell. If the comniumcations objea instance 1 10 is distributed via the pull technique, 
conuhunicadons network errors or distribiition server errors may also prevent an update from 
occuring, although the polling retry process can frequently correct this. A more likely sceiiario is 

30 that either the consumer computer 2 of tiie consumer program 22 is riot operated by the consumer 
during one complete version update cycle by the provider. For example, if the provider updates 
the comihimications object once per day, but the consumer does not operate the consumer 
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progr§ni;Z? ,fpr ft.»?eeiki thi? oon^uner may have missed six communications object versions. 
Finally, a communications olgect version cotdd become corrupted in the consumer database 21. 

If a uniform version value algdiiithm is used^throughout^ecdmihlihications object 
system to incrcineht the value of version Attributes of ebihmuiiic^fidiis dbjefet instances' 1 1 0 or its 
5 components, recovery of iost^r missing, versioiis is stfaightforwafd. When the piish technique of 
updating is used, recovery is accOniplished using a version moiiitorihg rule MO and version 
monitoring method 141 at the consumer program 22. These can be irapleiriented by th^ pbvider 
or the consumer. The version monitoring method 141 operates as a spfeiiiaizea data exchange 
method 141, explained above. The version monitoring rule 1 40 is associated with the 
10 communications object 11 0 so it is triggered each time an update is received. The v«!rsion 
moiiitoring rule 140 executes the version monitoring method 141 which compares the version 
value of the update received with version value of the most i«cent communications object 1 1 0 
stored in the consumer database 21. If the version value algorithm indicates that a version value 
is missing in the sequence, the version monitoring method 141 generates a message object 1 10 
15 containmg a data exchange element 143 specifying the missing version values and the system ID 
of the consumer. The version monitoring method Hlthen transmits the message object back to 
the provider program 12. Here, the message object executes a version monitoring receipt method 
141. The version monitoring method 141 then executes the communications object instance 
generation and transmission routine (FIG. 12) for the specified missing version communications 
20 object versions and the specified recipiem 120. When these new instances are received by the 
consumer program 22, synchronization is restored. 

When the pull technique of updating is used, the steps are slightly different In this case 
the version monitoring method 141 at the consumer program 22 needs to be able to determine the 
network address of the missing communications object versions on a distribution server 32. This 
25 can be done in several ways. A first technique is to use a version naming algorithm to derive the 
address from a combination of the network address of the current communications object 1 10 
and the. missing version value. For example, if the networic address of the current 
communicaUons object instance 1 10 is http://company.com/commobjecLcos and the missing 
version value is 348 1 , then the computed network address would be . 

30 http://company.co|ycommobject3481.cos. This requires two minor modifications toA^ 

communications object instance generation and transmission routine (FIG. 12). First, a step is 
added in which the version naming algorithm is used to rename a copy of the previous 
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commumcationsobject^yeFsion instance- 1 lO'stcned on' tbe local or network file system. 
AJtCTiadvely, the routine oodd regenerate this previous ixistanice if it were missii^v Second, at 
the conclusion of the routme, both the.current and- renamed previous version of the 
commtmications object 1 10 are transfcned to. the distribution server 32, Now v*en a new 
5 commimications object- iiistahce 1 10 is received at=ax6nsunicrprograni'22, tiie versid " . - 
monitoring rule 140 executes a version monitoring method 141. The version monitdrihg method 
1 4 1 first determines if any versiorvs: are missing. If so, it uses the version niaming alrogiithm to 
determine the network addresses of each missing communications object version. It then 
executes a polling operation for each missing communications object from the distribution server 
10 32, restoring synchronization. . 

A second technique is to store the date and neitwork address of previous versions in the 
communications object 1 10 itself. This iqiproach has the advantage of allowing any number of 
version naming algorithms to be used. This can be done with diree minor modifications to the 
conununications obj^t instance generation and transmission routine (FIG. 12). The first 
IS modification provides that each time a new version of a communications object instance 1 1 0 is 
generatedi:the:version'nanungtalgorithm is-.used'to^generale.a'unique^ addressname for 

this version. This unique network address name together with the version value and current date 
and-iime is stored as a archive composite-type element 1 43 contained in the communications 
object 1 10. This element is itself maintained by an archive rule 140 such that only n mstances, or 
20 only instances newer than X interval, are stored. The second modification is the same as 

described above, i.e., the communications object instance generation and transmission routine 
uses the unique network address name to rename a copy of the previous commuiucations object 
version instance 35 stored on the local or networic file system. Alternatively it could regenerate 
the previous instance of the communications object instance 35 it were missing. Finally, at the 
25 conclusion of the routine, both the current and renamed previous version of the conununications 
object instances 35 are be transferred to the distribution server 32. Now when the new 
communications object instance 35 is received at a consumer program 22, the version monitoring 
rule 140 executes a version monitoring method 141 as above. The version monitoring method 
141 compares the version value attributes of the archive elements 143 contained in the updated 
30 communications object instance 35 with those in the consumer database 2 1 . If any are missing, 
the version monitoring method 141 uses the network address stored in the archive element 1 43 to 
execute a polling operation for each missing communications object from the distribution server 
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32, restonpg sjrnchronu^tioQ. 

A thiid approach is to use a vasioh moiutoring iriethbd- 141 as ah eidiancement to the 
basic conimunications object update polling method desOTbSd above. This requires a dSstrilnition 
server 32 capabje of «xec«ting a data exchange, method, however it tremendously siihplififes 
5 version m^tQijitg. In this case^a vosion monitoring method 141 Operating at Ac consumer 
program ^ need only submit the UID and version value of the commimictdiohi bbjefct 1 10 to be 
updated to the. distribution serv* 32. The distribution server 32 then executes its own version 
monitoring method 141 to con^are the version value submitted with die version values of the 
archived communications object instances 1 10 stored on the server. The distribution server 32 
10 then returns to the consumer program 22 all missing versions. In a preferred embodiriient this 
process can be.automated using a distribution service object woricing in conjunction with a 
distribution partner server. Distribution service objects and partner servers will be discussed 
further below. 

In all of these approaches the version monitoring method 141 could also accept 
15 parameters used to control the quantity or dates of previous versions received. In this manner the 
consumer could specify that he/she only wishes to receive n past updates or updates back to X 
date. 

A communications object system can also automate a different forni of archiving 
commonly required of any software program using a database. This is the storage of backup 

20 copies of the provider database 11 or consumer database 21 in order to prevent data loss froih 
comjption, hardware failures, or other problems. In this case an archive method is ftmctioning as 
a data exchange method 141. Backup control can be accomplished using backup preferences 
stored as attributes of global preferences 103, or as special backup elements 143, together with 
backup methods 141. Backups can be performed manually, or automated using scheduled events 

25 instances 1 1 7. Backup services can also be automated via a data exchange service object, which 
will be further discussed below. 

Reporting and StfltistirQ r^nlTf^i 

Reports are typically one of the most valuable fimctions of any database system. In a 
communications object system, reports have particular value becaase they can be delivered 
30 automatically using the same system about which they are reporting: hi this sense reporting 
control is simply a speciaUzed case of data exchange control. Reporting control is especially 
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usefid to providers because it can give them valuable statistics and feedbadc about the 
conununications needs and behaviors of their audience. Reporting control can also be used by the 
operators of a conununications object system as the basis for billing ainid iicdosing* much as 
telephone usage reports are the basis for billing telephone> systral custorhers. 

5 As shown in FIG. 3» repbits can be compiled on any dass or group of classes in a ' 

database 100. These include specific coriununications object coiriporiehts 140, 141 , 14i2, 143, and 
144; individual communications objects 1 1 0; folders 1 1 5 or other groups of cbmmuriicationis 
objects 1 10; recipients 120; and events 1 16, s<dieduled events 117, and logged events 118, 
Reports which are locally useful to the provider or consumer can be defihed and executed using 

10 report instances 105. These reports are activated using the other reports fbrai (640, FIG, 1 3). 
Report instances 105 are in essence a special case of the overall reporting capabilities of the 
system. If a report does not exist as a report element 105, a report is generated using a reporting 
element 143 and a reporting method 141. Reporting methods 141 function as a special case of 
data exdiange methods 141, discussed above. As with data exchai^e methods, reporting 

15 methods are governed by reporting rules 140. Reporting niles function as a special case of data 
access rules .140,. discussed above. 

A unique feature of a communications object system is its ability to produce reports about 
the metadata jt.uses/to.control:Communications.:This.can.h^)^ communications 
object level and at the element level. A specific example is communications object subscription 

20 reports. Referring to.the example in the notification section above and illustrated in FIG. 4, in a 
communications object 110 a provider may create topic elements 201 from which a consumer 
can choose their notification preferences for topics of interest These preferences are stored in a 
element preferences instance 221. By including a reporting rule 140 and a reporting method 141 
in the communicauons object 110, the provider can be updated on any changes to user's 

25 preference element instances 22 1 . The reporting rule 1 40 operates as a data exchange rule 
monitoring the element preference instances 221 . When an element preference instance 221 is 
created or edited, the reporting rule 140 triggers the reporting method 141 which generates a 
message object 1 1 0. This message object contains the changed attribines of the preference 
element instances 22 1 . The reporting method 141 next transmits the message object back to the 

30 provider program 12. When it is received; the messi^e object calls another reporting method 141 
to process the reported data, for example by creating or updating associations to the recipient 
instance 1 20. The provider is now able to run reports 1 05 against this data in the provider 
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d^ba$e. II tp. prpdupi; statistics 8t|()ut c^mmuiucations object usage. Iliese can include the total 
sul^n);qr$.t||p, tQ ai^y^C^QiQl^limipaticns object 110. as well as tiie total subscaribeiship to any 
pardculv tQ[nc:el^{^ 201 . In this way fhit provider can see the precise coinnnmicatidhs needs 
of the i^oyi^i's.aij d.ie!w;e ,.This 
5 cotnm^qitipns tppics and iiiessages to better meet the. needs of this audience. Alternatively, the 
("St li^rtiBg method 141 can transmit a message object llOor another form of structured 
message to another reporting server.. Reports can be geheratisd in the same fashion at this 
reporting server. This process can al^o be automated using leportii^ sendee objects, which will 
be further discussed below. 

10 In addition to control of metadata, reports can also nibhitor commu^cations activity. 

Continuing the example above, a communications object 1 10 can include a reportiiig rule 140 
which monitors access to any message element instance (21 1 , FIG. 4) contained in the 
communications object 110. When At message element is read fiwm the consumer database 2 1 
for the first time (i.e. read by the consumer), the reporting nile 140 is triggered. This executes a 
15 method 141 that creates a logged event instance 1 1 8 recording the UID of the ooiiimtihications 
object 1 10 and message element (211, FIG. 4). The communications object 1 10 can also include 
a receipt method 141 that creates a scheduled event instance 1 1 7. This scheduled event instance 
wUl periodically execute a reporting method 141 which queries the consumer database 21 for 
new logged event instances 1 1,8 matching the UID of the communications object 110 and the 
20 appropriate event type. This reporting method 14 1 can then produce a message object reporting 
the results as explained above. Any data present in the queue of logged event instances 1 18 can 
be reported on in tiiis feshion. As with otiier forms of data exchange, protection of both provider 
and consumer security is achievable through the use of reporting rules 1 40. Such rules can limit 
reporting access, for, example, to logged event instances 1 1 8 which matched a particular 
25 communications object UID or a provider group UID. 

For many reasons, including efficiency, security, and consumer anonymity, reporting 
control may operate at tiie system level. In tiiis case, reports may be aggregated for providers by 
the system operators using a reporting server or ^stem of servers using reporting service objects. 
System level reporting may also be used to enforce licensing rules and create billing and sen-ice 
30 reports. Reporting service objects and reporting partnCT servers will^belurtiierdiK^ 
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As described above/sorvide objects are a speciki class of cdnmuriications object >^ose 
primary funcdon is td provide' connniiiucatibm bbmmunicatidhs object. A 

. service object is used to coordinate cbimrnmicatiohs between providers suid users. The server 
which provides mi operates on a service object is neferxied to as the service dbjecfs *'pa[rtner 
5 server"; As with: any coimnunicatibns object^ the * 
metadata, and methods. Since different users can xitilize a service object having certain features, 
actions between users or by different users can be' Coordinated by tiie servicVbbject A provider 
may include features from a received service objea in its own cdmmuhicaliohs objects. A user 
may also use the methods in the service object to perform routine conunuhication functions with 
10 others, including a third party partner serv^ v/tdch created the service object A service object 
can include any data, metadata, or methods which are useful to a significant number of providers 
or consumers. Various types of service objects and service providers are discussed below as 
examples. . These examples relate to common functions to be performed in the commimication 
system, and illustrate the operation of service objects. Of course, many other service objects 
IS having different features and functions could be created and used in connection with the 
communication system; 

Any given service object (8 15, FIG. 1 7) may provide services to providers, consumers, or 
both;.Servfice:objects;that :offer:seivices:to both providers and<consumers are calied polymoiphic. 
Polymorphic service objects-are particularly, useful in.a communications object system because , 
20 many of the same services are required by both partners to a conununications relationship, each 
in a dififerent form depending on whether the partner is the provider or consumer. Such services 
typically fall into three categories: editmg or searching databases, encoding or decoding 
communications, and automating transactions with third parties. An example of the first category 
is a directory service object, which pemiits providers to place or update listings in a directory 
25 service and permits consumers to automate searches of the same directory service for a specific 
provider. An example of.the second category is an authentication service object, which permits 
providers to digitally sign communications objects and permits consumers to automatically 
verify these digital signatures. An example of the third category is a payment service object, 
which permits a provider to automate receiviiig payments from a bank or credit company and 
30 permits consumers to automate sending paythents to the bank or credit company. Alternatively* 
where it is more efficient, service objects can be split into provider/consumer "pairs", each 
containing a link component object 1 1 0 linking it to the other. 
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. §|p!}?<! object? can wholly contain thc,,socyices they offer, or they can represent the 
service^ 6f pue gr m9Jp wrviws ayaiiatjie in the conununication^ object ^stem. In the latter case, 
the sendee Qlyect f^ps tlie basis fQr .commuiiicatiQg.j^e necessaiy inforo^on to the sraver so 
that fb? sejyioe cm bis f^^isi. The. laftei: case is also pwtiwilarly usefiil hescause the service 
5 object «9.#bsti:act .pr "cnc^psBlate" the, mterSau to the saver or-^SCTvers, removuig the need for 
either die pftm^ or jCcnistUDier to deal with thjs coinplexity. A service object may represent 
services provided by a network of related servers, fpi; exampljR a replicated directory database 
such as the Internet's Domain Naine Service (DNS). The. service object can then also abstract 
and automate die process of choosing one of the network servos as a current partner server 

10 which will resiUt.in optimal performance and minimal network traffic. Referring to FIG. 3, this 
feature is accomplished by including a receipt method 141 in the service object (815, FIG. 17) 
having one or more algorithms for determining the optimal parmer server. Such algorithms can 
access elements 143 in the provider database 1 1 or consumer database 21 for necessary input 
data such as the user's geographic location, time zone, network address, and so on, or they can 

15 prompt the user for such data via input forms. The service object's receipt method may. also use a 
data exchange method 1 41 to query a reference server, perform network packet timing tests, or 
use odier techniques to determine the optimal partner server. The same qqiroach can also be used 
to determine one or more backup partner servers to use in case the primary partner server is 
unavailable. The particular algorithm or niethod for determing an optimal partaer s»ver or 

20 backup partner servers is not a limiting feature of the invention. Once determined, the receipt 
method can save this data in the provider database 1 1 or consumer database 21 as oiie or more 
element preference instances 147. Thesfe element preference instances can then be accessed by 
the service object's update method 141 or any of its other methods whenever it needs to call 
operations at the partner server. 

25 Service objects are distinguished in a communications object system by tiieir 

communications object type. Examples of service object types are shown as classes 830 - 844 in 
FIG. 1,7. Service object types serve the same function at the communications object level as 
element types serve at tiie element level. Service object typing allows tiie programs 12. 22 and 
other communications objects to make calls to service objects by type. When more than one 

30 service object of tiie proper type is present. Uie programs 1 2. 22 can prompt Uie provider or 
consumer to choose tiie desired service object, or tiie programs 12, 22 can make tiie choice, 
programmaticaliy. For example, a provider seeking to list a new communications object in one or 



eNSOOCB): <lMO_S73225U1J.> 



-Wd 97/35151 l^/ibs97/0i32O« 

-130- 

mote directoriesxould exe&ute ai systemrme^cKi141 that would call all direictdry service objects 
832 present in'^ provid^-database 1 1 . tf more than oiie vias preismt; tlie systein method 141 
would generate ah input forth prbmptihg tiie provider to choose the desired directory service 
object or objects 832. When this foitn was submitted by the prd>)^ide^, the syston method would 

5 proceed to call a DirectoiyList method^of each directory service bbject 832. the Directory List 
method for each directory service obj^t woiiid then carry ouit the balance of the operations 
needed to complete the diretctpry listing. 

The same fundamental data structures used in the provider database 1 1 and consumer 
database 2 1 can be used in a partner server database 1 301 . These data structures are shown in 

10 FIGS. 3 and 4. Service objects (815, FIG. 17) can be stored as communications objects 1 10. 
They can also be nested ais composite aind component objects (81 1, 812, FIG. 17) using 
association 1 1 OA as explairied above in the description of composite and component objects. The 
use of composite and coni|K)hent service objects is ideally suited to many partner server 
functions, as fiuither explained below. Alternatively, partner servers can use other data structures 

15 in order to optimize database performance, particularly for high-volume applications. Such 
additioiia];data structures may;.include.the use ofspecial. indexes orindexing algorithms, special 
cadies or cache techiuques, and other database performance enhancement technologies. 

The same.basic.program:operations;used in the program 12, 22 .can be used in a partner, 
server 1 302. In particular^ a partner server 1302 may use the same HTML and HTTP interface 

20 system as described for the programs 12, 22. This allows the partner server 1 302 to function as a 
web server for human interaction via a browser 50, while at the same lime providing automated 
interaction \vith the programs 12, 22 via the HTTP protocol and any other mutual protocol such 
as SMTP/MIME. 

As a subclass of standard communicaiions objects 1 10, service objects can include all the 
25 control functions of commimi cations objects described above. Certain control functions have 
special relevance for service objects. First, link control allows other communications objects to 
call the methods of a service object object regardless of where the service object may be located 
on a communicaiions network 3. The special applications of link control will be discussed below. 
Second, update control allows a service object to stay current regardless of where it is located on 
30 a conununications network 3 . Version monitoring and update querying are particularly efficient 
techniques of update control for service objects and will be discussed below. Third, notification 
control allows a service object provider to notify providers oi consumers using the service object 
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about relevant changes tQ the service obj^t or the communications services it makes available. 
Fourt)i« data exchange, control allows the service object to automate datia exchanges with the 
server or sep^eirs the service object may represent, Fiilbi data archive control allows service 
objects tQ delete theoiselves if they age beyond a certain date or have not been used within a 
5 certun ppripd. This aUo:ws data^bases 100 to avoid aii? accumulation of seldom-used service 
objects,. Finally, event tracking control and reporting control allows service objects to create and 
report transa(^on records wMch can be processed to provide further services to the provider or 
consumer. These transaction records can also used by the service object provider for billing or 
statistical purposes. 

10 Link control and update control have special applications to polymoiphic service objects. 

The application of link control to polymorphic service objects is illustrated in FIG. 28. A 
provider using the provider program 1 2 has need of the services offered by a service object 
partner server 1302. First the provider obtains a service object 1310 fiom the partner server ! 302 
(step 1320). This may be by browsing with a web browser 50, recei\ang the service object 1310 

15 via e-mail, or any of the oAer techniques described above. Such partner server 1302 may be a 
dUtribution server 32 or any other type of service object partner server such as those described 
below. Once the provider has obtained the service object 13 10. the provider may add a link 
component object 1 10 to any of the provider's communications objects 1 10 which need to access 
the elements or methods the service object 1310. This link .component object 1 10 will then be 

20 included in any communications object instance 35 generated from the consumer database 2 ! 
(step 1321). In a preferred embodiment, the link component object 1 10 is supplied by the service 
object 1310 itself In this case, referring to FIG. 3, the provider need only create a contained-by 
association between the link component object 1 10 in the service object (1310, FIG. 28) and the 
provider's communications object 110. This association can also be created automatically when 

25 any service object method 141 is executed that creates a service relationship between the service 
object and the communications object 1 1 0. The communications object 1 1 0 thus becomes a 
synthesized object (813, FIG. 17), wherein the link component object 1 10 is supplied by the 
service object 1 3 10. Examples of such a service object relationship include listing a 
communications object 1 10 in a directory server, registering a communications object 110 vdth 

30 an authentication server, or authorizing a communications object 1 10 for use with a payment 
server. Further examples will be given below. Referring again to FIG. 28, the next step is that a 
conununications object instance 35 is transferred to a consumer program 22 (step 1322)..This 
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may he via e-mail using^^ push Ceclmique, m a distribution sSiyer 32 using the pull technique, 
or any of the other techniques desieribed aBove: Once the cbininuhicati&ni 6bje^ mstahte 35 is 
transfenred to the consumer imgram 22, a link me&ibd 141 of the link conipdiieht objeci 1 10 
may be manually executed by the cdnsuiiier or automatically executed by another system method 
5 or communications object method. For example, the consumer may wii^ to look up i^j^ed 
communications objects instances 35 in a directory server, or aiithehticate the cbmnlimications 
object instance 35 before forwarding it, or tnake a payment transactibn using the 
communications object instance 35. Wheii the liiik method 141 is executed, it u^es the attributes 
of the link clement 1 43 to locate the designated service object 1 3 1 0 as described in the 

10 communications object exchange control section above. For example, if the service objeci 1 3 1 0 
is not present locally in the consumer database 2 1 , the link method uses other attributes of the 
link element to locate the service object 1310. For instance, if a URL was present, the link ' 
method would use it to obtain the service object 1 3 1 0. If this fails, the link method would use the 
yiD. or name of the service object 1310 to obtain its URL or other cuitent network address via a 

15 name server. The link method could also call the methods of a name service object, described 
below..Qnce.the link method located-the.proper-netwoA address, it would download the service 
object 1310 from the partner.server 1302 (step 1323): At this point die link is reestablished, and 
the conomunications object instance 35.can.caU.the.ser^ 1310 to . 

perform the services requested (step 1324).: 

20 Once a service object 1 3 10 has been transferred to a consumer database 21 via this 

technique, version monitoring can be a very efficient update control technique. This is because 
the services of the service object 1310 may not be required again until they are called by another 
conununications object instance 35. Version monitoring can be employed as follows. First, the 
service object 13 10 can use a standard push or pull update control technique at the provider 

25 program 12 to maintain a current version. Such version changes will also maintain current 

version values in any hrik element 143 associated with the service object 1310. By including this 
link element 143 in any update of a conmiunications object 1 1 0 which contains it, the link 
element 143 will be transferred to all recipient consumer programs 22 when the conununications 
object 1 10 is updated. At this point, whenever a method call is made from a communications 

30 object instance>35.to the service object 1310, a version monitoring rule 140 conudned in the 
service object 1310 can be triggered. The version monitoring hile 140 compares the service 
object version value stored in the link element of the calling communications object 1 10 with the 
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VCT^iftn value, of the, service object la i Oi-If the version value in the link element 143 is greater 
than fte version value of jtt(^,se3yice object I31Q, the update method of die service object 1310 is 
executed ^nd the service olgect 13 10 is updated prior to completion of the original si^ice object 
method call. 

5 Update queries are also a highly efficient iqxiate contiol technique for service bbjects. 

This is especially true Miien a service object 1310 is used to represent access to a large database 
of conmiunications objects 1 10, such as the categories of a yellow pages directory server or a 
classified advertising server. Basic update query control is explained in the update control 
section aBbve. When used in conjunction with a service object 13 10 and partner server 1302, 
10 update qucjry control can be even Ai6re efficient by employing user objects 1 1 0 on the partner 
server 1302. The data sthicttires for user objects are shown in FIG. 6B. User objects 1 10 
represent either the providers or consumers mteracting with the partner server 1 302. The partner 
server 1 302 maintains an index of the provider and consumer relationship associations 111 
between all conmiunicaitions objects 1 10 and the user objects 1 10. Updates to communications 
15 objects 1 1 0 in the partner server database 1301 set the NewFlag attribute value of the 

relationship association t6 TRUE This can be accomplished very efficiently on the partner server 
1302 using an update association rule 140 and the update association routine (FIG. lOB). By 
employing such a user object index, an update query method 141 of a service object 1310 need 
only submit the provider UID in its update query. The partner server 1302 executes the query 
20 against the user object index to determine all conununications objects 1 1 0 associated witii that 
user UID where the NewFlag attribute value is TRUE. Those communications objects 1 10 are 
returned irximediately as the query result set and the NewFlag attribute for each of these 
relationship associations 1 1 1 is reset to FALSE. User objects 1 1 0 can also act as recipients 120. 
In this case the partner server 1302 can transmit communications object updates via the push 
25 technique. The data and methods in user objects 1 1 0 on a partner server 1 302 can be 

automatically kept current by a data exchange nile 1 40 in the service object 1 3 1 0 as explained in 
the data exchange control section. The use of user objects 11 0 in a communications object 
system can be better understood in the discussion of multiuser operation in the advanced 
architecture sections below. 

30 The following sections will explain how service objects .and partner servers can be 

employed lo iMt)vide registration, maintenance, name, directory, distribution, encoding, 
autiientication, data exchange, payment, reporting, and feedback services for a communications 
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o))jiBct system; This set of service object cqjplications is not dQlaustive biit inerely illusuative of 
hovr service objects may be employed. Seivice objects md piithie^ niay also combine any 

number of services. Alternatively, any of the seiVices described bcilow may also be performed 
directly by one or more system methods 141, rules 140, and elements 143 instead of service 
5 objects 1310. Service objects are a preferred embodiment because tbeyialloW such services to be 
. encapsulated, distributed, optimized, and updated throughout a conununicatiohs network 3. 

Rgeistraiion Sgnige Qbjgcts mci Partner Sgrvm 

A registration service object type (830, FIG. 17) can be used to obtain the initial database 
system ID (100, FIG. 3) used to tmiquely identify a provider database 1 1 or consumer database 

10 21 . This process is explained in the system ID and naming services section above. As illustrated 
in FIG. S, if a communications object system only re^quires one system ID server 42 (also called a 
registration parmer server), registration services are easily be accomplished using a system 
method 141 . However, this same process can also be used to obtain other system IDs which can 
function as group IDs, registration keys, licensing keys, and so on. In this case multiple 

15 registration partner servers may be desirable. For example, in addition to a global.lntemet-wide, 
registration server, a company may wish to have its own registration partner server to manage 
communications object system group IDs and authorization keys for its employees. By creating 
its own registration service object, thexompany can quickly and easily.add these services to the 
programs 12, 22. 

20 Registration partner servers.can do more than just automate and track system ID and 

group ID assignments. By including data exchange methods for other registration data, such as 
names, addresses, contact information, and so on, registration panner servers can obtain and 
store all the information necessary to fully register communications object ^stem users. By 
using data exchange methods to return registmtion keys and licensing keys to the databases 1 1 , 

25 21 which enable the operation of all or selected subsets of feanires, registration parmer servers 
also function as licensing servers. For this reason registration servers can be efficiently coupled 
with naming, authentication, and reporting service objects and parmer servers. 

Maintenance Service Objects and Partner Servers 

A maintenance service object type (83 1 , FIG. 1 7) can be used to acquire, maintain, and 
30 register cdiximunicatibns object system components from a system maintenance parmer server 
1302. This can cover any communicatidns object system component that eniploys versioning. 
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R^^f^.6g^P FIQ; 3, this inqludes. rules ro?thsds. 141, pages 142. elements 143, and type 
definitions 144. 

If all the (components o^ die programs l?, 22 arc. stored as one of these classes, the use of 
maintenance iservice objcjpts 1310 tq monitor and update ihese components enables the programs 
5 in a coixunynications object system to be.se|feupdatmg.. Existing components can be updated, 
new cpiiippftents can be downloaded as required, and outdated components can be deleted. 

Maintenance service objects 1310 also allowi all the providers in a communications 
object system to contribute and obtain new system components. This is accomplished by 
including a data exchange method 141 in the maintenance service object 1310 that automates the 
10 process of uploading and registering the hew components in a database 1301 at a maintenance 
partner seryer 1302. Another data query method 141 in the same maintenance service object 
1310 allows other providers to manually or automatically search the maintenance partner server 
database 1 301 . This process is folly described in the data exchange service object section below. 
The sharing of communications object components across a communications object system is 
15 particularly valuable in relation to niles 140, methods 141, and type definitions 144. New rules 
and methods allow providers to extend the functionality of the communications object system 
easily. For example, new system objects can encapsulate the services of particular 
communications protocols. These include network protocols, such as TCP/IP, IPX/SPX, and 
NetBEUI; conununications protocols, such as XMODEM, YMODEM, HTTP, NNTP, and 
20 SMTP; APIs such as TAPI, MAPI, and Visual Basic; and even device driver protocols such as 
those required for printers, modems, CD-ROM drives, monitors, and so on. The particular 
protocols used are not a limiting feature of the invention. Since newer, more powerfiil, more 
efficient, and more secure protocols are always evolving, encapsulating these in component 
communications objects that can be easily distributed throughout a communications object 
25 system is a major advantage. 

New type definitions allow groups of providers to create shared data structures that meet 
particular needs, such as specialized elecu-onic data interchange (EDI) standards for vertical 
markets. Shared type definition repositories have particular applications that enable new types of 
intelligent information interchange. An example discussed above in the data exchange conu-ol 
30 section is the customization of web server content for Web browser users. This interchange can 
be substantially enhanced through the establishment on a maintenance partner server 1 302 or a 
distributed networic of partner servers 1302 of a server database 1301 of shared type definition 
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instaiices 1 44. Th& type deiSiiitidh instm!^ coiild cover families of comnioh psychographic 
variables such as political affiliations, color preferences, food and beverage preferences, 
entertaimnerit preferences; arid 'ot^ 1310, providers can 

search for arid dowilioiad these type definitions 144 to be incoiporated into the design of the 

5 provider's web content customization' syste^m ^ weU as the provider's owb 

objects 1 10. When a cdhsinhCT trowses the provider's web sehi^d'/the web senrelf can retiirri a 
communications object 1 10 th^ queries the consumer database 21 for the values of elements 143 
corresponding to specified psychgraphic type definitions 144. If these type definitions are not 
present, the cdnununications object 1 1 0 will include a link component object 1 10 to obtain the 

10 necessary type defuiitions 144 from the maintenance serv^ 1302. The communications object 
1 10 then generates an input form requesting the values for elements 143 correspbndiiig to each 
type definition. Once these element prefacnce instances 147 are saved in the consumer database 
2lVthe consumer need not enter this pschognq>hic preference data again. It will be available 
automatically to any other provider who needs it» subject to data access rules 140 applied by the 

15 consumer. In this way the consumer database 21 can steadily grow "smarter" about the ' 
consumerls interests;and.tastes,:and providers have a highly direct; efficient;' and automated • 
mechanism with which to obtain such psychographic data from the consumer.\ 

This process can be gencrailized'.to any set of data types that need to.be shared amongst a. 
group of providers. This includes many vertical market applications, such as industrial part types, 

20 chemical types, academic research types, business application types, software programming 
object types, and so on. The specific data type service is not a limiting feature of the invention. 

Name Service Objects and Partner Servers 

A name service object type (832, FIG. 1 7) can be used to register and search 
communications object names or any other kind of names on a name parmer server. A name 
25 service object is an excellent example of a polymorphic service object because the same service 
object used by a provider or a provider program 12 to list or edit a communications object name 
with a name partner server can be used by a consumer or a consumer program 22 to locate 
communications objects using the name partner server. 

The use of naming and name resolution services in a communications object system are 
30 fully discussed, in the communications object exchange control section above. A name partner 
server 1302 can implement nmie services, usii^ many database structures. In a preferred 
embodiment name services for individuals are provided using communications objects 1 10 of 
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the user object typei..(8 1 6. FIQ; 17). Rrferring to FIG; 3. a basic "vdiite pages" name service can 
be iinpleniented:usi^^ element 143 af a composite type UniqueName for each user object 1 10 
list^, A user pbj^t 1 l.Q topuid have more than one unique name by ailowixig more thaii 
UiuqiuiHame eleinent .1.43 to be a^^iated with the user object 1 1 0. Alteinnate niuneis may also be 

5 desirable, for exaniple tp allow individuals using^nicknames to be located using the nickname. 
Alternative names are also advantageous in a commercial tradenamie name service because it 
allows, companies who use the same tradeitiark nanrie across different industries to all reference 
that name. Alternate names can be created using an element 143 of the communications object 
1 10 with the composite type AltemateName. By including methods 141 for listing and editing a 

10 name as well as searching for a unique name or an alternate names, a name service object 1 10 
can automate name server access for both providers and consumers. 

Name service objects 1110 and name partner servers 1 302 allow multiple naming 
systems to be employed in a communications object system, either globally or across any subset 
of the system. A global communications object system name is particularly valuable to 

15 individuals because it allows them to obtain a lifetime communications address that never needs 
to change regardless of any changes to specific conununications network addresses the individual 
may hold. This address may also be completely identical to the. individual's real name if such a 
name is unique in the naming system. The same advantage may be realized by organi2:ations 
using tradenames for their company, product, or service. 

20 Other advantages of communications object system naming services are enumerated in 

the communications object exchange control section above. Besides individual names aiid 
conmiercial trademark names, communications object system naming services can be applied to 
many specialized or vertical market naming needs such as industrial part names; research topic 
names; corporate department, group, or project names; software progranmiing object names; and 

25 so on. The specific nanung service used is not a liniiting feature of the invention. 

Directory Service Objects and Partner Servers 

A directory service object type (833, FIG. 17) and a directory partner server 1302 provide 
an extension to name services whereby communications objects can be listed and located by 
additional attributes. Any attribute that enables consumers to locate communications objects of 
30 interest may be employed. For example, consumers may wish to locate user objects 110 

representing other consumers. In this case, desirable attributes may include geographic location, 
age, occupation, family lineage, educational affiliation, political affiUation, religious affiliation. 
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and SO OIL These attributes may all be iepresented'ty. different elements 1 43 in a dirc^iy 
partner server 1302 in the same nianiier as described abdve for psydiographic attributes on a type 
definition niaintoaatice server/ Wfaen a provider of a comihimicatims dbj^t 110 uses a directory 
service object 1310 to create a directory listing on the diiwtory partner server 1302; a data ' 
5 exchange mediod 141 in the service object uses the system ID of thefyjkj defihitidri 144 for each 
r^uired or desired attributed automatically identify arid copy these ^tributes from eleitients 
143 in the provider databaise 11 to elements 143 ih thedii«noiy paiteef sei^ 1301. 

Another cominoiiiy desired set of directory a^biites is a hierarchiciil categozizi^tion 
system such as that employed by many "yellow pages" directories. In a preferred embodiment, 

10 such a categorization system is iiriplemented on a directoiy paiirier sert^eir 1 302 using ci^ihposite 
communications objects (81 1 , FIG. 1 7) arid component commuriicisitidns objects (8 1 2, FIG. 1 7), 
Such a data smicture is illustrated in FIG. 29A. The directory service object 1401 functions as 
tiie highest-level composite communications object Each of its first-level component objects 
represents die top-level categories 1410, 1411, 1413. These component objects are called 

15 category objects. Component objects of each top-level category object represent the second-level 
categoriesJ421;.1422, .1423,J424;;Such a category object structure-can;be nested as many layers 
deep.as is necessary.. Alternatively, a separate directory service object 1401 could represent a 
particular branch within the categoiy structure.^ : 

The use of a communications object-based directory service offers several advantages 

20 over conventional directory systems. First, it can simplify and automate flie listing process for 
providers. The steps in this process are illustrated in FIG. 30. In this example a directory system 
is implemented on a directory partner server 1302 as a web server using HTML pages to display 
the category hierarchy. Each category description includes a hyperlink to its category object 110. 
The process begins vsdth the provider using his/her browser 50 to navigate the directory partner 

25 server 1302, The provider chooses the hyperlink representing each category object 1 10 in which 
the provider is interested in listing a communications object 1 10 (step 4001). The receipt method 
for the category object 1 10 first checks to see if its parent directory service object 1310 is present 
in the provider database 1 1 (step 4002). If not, the category object uses its link component object 
1 10 to download the directory service object 1310 from the directory partner server 1302 (step 

30 4003). Next the receipt method 141 for each category object 1 10 generates an input form 

prompting the provider for tiie communications object or objects 1 10 to be listed in this category 
(step 4004). When this input form is submitted, the receipt method creates an association 
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b^i^n the i;^)^ or objects 1 10 and the c^tegQd^^pbji^ 1 10 (step.4jQQ5). 

Finally, the receipt m(^od .141 asks the provider if he/she would like to choose additional 
. (^gQry .Ql>je^Xsjy^^06)v If so^ th^ ahp^ye. step^care repe^ On(^ .the provider has chosen all 
desired categpjry objects 1 IQ, the provider executes a da|a exchange, method 141 in the directory 
5 service pbj^ 1310 thfit will put;lhe listing prpcediro (^:40Q7).^ This dataexchange 
method .141 quenes.the proyider database. Ufor all caUsgpiy objects 4 jOJ^^^ to the 
directpiy service pl)ject I310(step.4p.p%The^^^^ then queries for all of 

the provider's cprnmunications objects: J 10 associated with these category objects 1 10 (step 
4009). The data exchange method 141 creates a message object 1 10 containing this query result 

10 set together with Ae necessaiy ajftributes or elements of the listed communications object or 
objects 1 1 0 (step 401 0). The data exchange method 141 transmits this message object 1 1 0 to the 
directory partner sender 1302 (step 401 1). When received by the directory partner server 1302, 
the message object 1 10 triggers a corresponding data exchange method 141 (step 4012). This 
data exchange method 141 creates or modifies the listing for each communications object or 

15 objects 110 in the directory partner server database 1301 (step 4013). This listing consists ofa 
new component object 1 1 0 containing the desired listing elements 143. The data exchange 
method 141 then creates the appropriate associations with each composite category object 1 10 
(step 40 14). When this process is completed, the data exchange method 141 creates a message 
object 1 1 0 containing an appropriate acknowledgment message (step 4015). The data exchange 

20 method 141 transmits this message object 1 10 back to the directory service object 1310 at the 
provider program 12 (step 4016). When received by the directory service object 1310. the 
message object 110 executes its receipt method 141 (step 4017). The receipt method 141 
executes the provider's desired notification method 141 to complete the listing (step 4018). this 
directory listing process can also include authentication services, payment, or reporting services 

25 as further described below. 

A second advantage of a communications object-based directory service is that it 
automates the directory updating process in botii directions. The steps in the process of updating 
a provider's listings on a directory partner server 1302 are shown in FIG. 31 A. This process 
employs a data exchange rule 1 40 in the directory service object 1310, explained in the data 
30 exchange control section above. The data exchange rule 140 monitors for changes in atuibutes or 
elements 143 of a communications object 1 1 0 associated witii a category object 1 1 0 or a 
directory service object 1310 (step 403 1 ). When such changes occur, the data, exchange rule 
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triggers a exc^^ge meihdd.141 iii the difectbfy seivice object 1310 (step 4032). The data 
excl^ge melbod creates a message dbject 1 10 rontaihiing tBose changes (st^ 4033^. The 
data exchangemeth6d;M message Object 1 10 to flic dtiiectbry jxEfftner serVer 1302 

(stej) 4034): \liiieniiiiciY&l by the directory parCiieif s«var 1302, the inessagfc object 1 10 triggers 
5 a dorrfepdiidihg datk exdhmge methdd 141 (sfi^ 4035)/11us d^ite^^^ 141 updates 

the neces&uy attributes aUd ass6ciations in the (tirectoty parthd' server diiitabs^ liOl (step 
4036). If desir^ data exchange niethbd 141 also retinis aii aclmowledgirieht message object 
1 10 to the directory' service object 1310 at the pfovidet prbgriaim 12 to confirm the update has 
beehmajde. 

10 The steps in the process of notifying a pix>vider about changes to one or more categoiy 

objects oh the dir&tory partner server 1302 are shown in FIG; 31B. Such changes occur v*en a 
category definition is changed, the directory fnovider needs to bifurcate a directory category, into 
two or moi^ categories, when a category is replaced by another category or categories, and so on. 
This process uses the update query technique described in the update control secdon above to 
15 monitor the directory partner server 1302 for chianges. When the first directory listing is made 
by the directory service object 1310, the data exchange method 141 creates a scheduled event 
instance 1 17 in the provider database.l 1 (step 4051); When activated, the scheduled event 
instance 117 triggers.a update query method 141 in the directory service object 13 10 (step .4052). 
The update query method. 141 first queries the provider, database 1:1 for the .UID and version 
20 value of ail category objects 1 1 0 associated with the directory service object 1310 (step 4053). 
Alternatively, an index of these values could be maintained as an element in the directory service 
object 1310. The update query method 141 then creates a message object 1 10 containing the 
result set (step 4054). The update query method 1 4 1 transmits tWs message object 1 1 0 to the 
directory partner server 1302 (step 4055). When received by the directory partner server 1302, 
25 tile message object 1 10 triggers a corresponding update query method 141 (step 4056). This 
update queiy metiiod 141 uses the message object result set to query the directory partner server 
database 1301 for any changes to the corresponding category objects 1 10 (step 4057). The update 
query ihethod 141 then remms the.result set to the provider program 12 (step 4058). If there are 
no changesV die result set is a message object 1 1 0. If there have been changes, tiie result set is die 
30 changed category objects 1 1 0. The provider program 1 2 receives the result set and executes any 
receipt methods pertaining to die result set objects (step 4059). This includes the notification test 
(step 4060). If die provider desires notification of changes to directory category objects upon 
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which jl}e pjoyiidliei^^njsy.w^ to take action, the provider program 12 executes the desired 
notification methods (step 4061). 

Altematiyely, for high-volume aiqdications, the directory parmer server 1302 can 
maintain an index of the provider UIDs asspciated with each category object 1 1 0. These UIDs 
5 can be stored in user objects 1 10. In this caise step 4053 can be eliminated^ and the update query 
in Step 4054 can consist of just the provider UID. The provider user obje<ns 1 10 can also function 
as recipients 120 on the directory partner server 1302, In this case, updated category objects can 
be distributed using the push technique. This process is explained in the service object 
introduction section above. 

10 A third advantage of a communications object-based directory service is that consumers 

may use a directory service object 1 310 to monitor a directoiy partner server 1 302 for new 
listings in any category or changes to the category structure. Because they are symmetric and can 
be poformed by a polymorphic directory service object 1310, these processes are largely 
identical to those described above for a provider. In addition, daita exchange methods in a 

15 directory service object 1310 can allow consumers to create custom queries that can be run at 
scheduled intervals against the directory server 1302. thus a consumer could, for example, be 
notified if any new listing containing the word "Mustang" was added to a directory server 1302 
even if there was no "Mustang" category object 1 10. This is further discussed in the section on 
data exchange service objects below. 

20 The value of a communications object-based directory services can be further increased 

using link control. Any provider who associates (lists) a communications object 1 1 0 with one or 
more category objects 110 on a directory partner server 1302 can include a link component 
object 1 1 0 from those category objects 1 1 0 in the communications object 1 1 0. This is identical to 
the process ofinciuding a link component object 11 0 from a service object 1310 as described 

25 above. Category object links provide a powerful new way for.constimers to locate 

communications objects in which they are interested. The consumer can just activate the link 
method 1 4 1 to immediately download the desired category object 1 1 0 and access directory 
listings for other communications objects 1 10 in the same category. Using the dir^iory service 
object 1310 linked to the category object 1 10, the consumer can also immediately'begin 

30 monitoring the directory partner server 1302 for new listings in that category. 

Directory partner servers are well-suited to be combified with distribution partner servers 
and data exchange partner servers because it is easy to create and maintain associations in a 
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single database 100 Between directory category objects 1 10, the Ih^ted cbminunicatidns objects 
110, elements 143 associated with the communications objects 1 10, and user objects i 1 0. 

Since a conuriuiiicatioris object can rcpfeserit anything which a pifovider wishes to 
conuhunicate, the advantages of a cbmmimicatjdns object systian directory service can be' 
5 transfered to any real-world function where diiectbry services aire usefiil: Besides conventional 
white pages and yellow pi^es, this includes catalog^, professional and academic directories, 
computer network directories, personal address hbdks^ classifled advertising services, and so on. 
The speciflc directory service is not a limiting feature of the invention. 

Distribution Servic e Objects and Partner Servers 

10 A distribution service object type (834, FIG. 1 7) can automate the transmission, storage, 

and updating of communications objects on a distribution partner server 1302. While any server 
on a commimications netwoiic 3 capable of file storage and retrieval can operate as a distribution 
server 32, a distribution partner server 1302 which includes the full capabilities of a database 100 
offers many additional services to communications object providers and consumers. 

15 The first of these advantages is the.automated .transmission.of communications objects . . 

and communications object updates from the provider program:12 to the.distribution partner ~ 
server 1302. This is accomplished.through the use of a data exchange method 141 in the. 
distribution service object 1310. Referring to FIG. 12, this data exchange method is. called at step. 
550 of the object instance generation and transmission routine. The distribution service object 

20 1310 then carries out step 551 before returning to the calling routine. If multiple communications 
objects or object updates are to be transmitted to the same distribution server 32, the distribution 
service object 1 3 1 0 aggregates these and performs fewer, more efficient transmissions. 

The inverse of this process becomes a key advantage for consumers because a single 
distribution service object 1310 can use the update query technique to monitor a distribution 

25 partner server 1 302 for updates to all communications objects 1 1 0 associated with the 
distribi^ion service object 1310. The greater the number of communications objects 110 
associated with a single distribuUon service object 1310, the more efficient the update process 
becomes. Only a smgle update query needs to be made to the distribution partner server 1302.. 
This update query technique is further described, in the update cpntrol and director}' service 

30 object sections above. This technique is particularly efficient when used in conjunction with a 
user object 1 10 index at the distribution partner server 1302. User object indexes are explained in 
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thesoryi^obje^^^ 

A second advantage to providers is that the distribtiiidh partner servfer 1362 caii dffload 
the work oftrwisnutting ccm^ updates via the push technique;: For lacfge 

numbfersi of recipients 120, ermsiil generation and trahsinissioh can require ambijtnt^ of 
5 wqptputer processor time and M a distrii>uti<yii pkiiH^r server 

1302 can free the operation of the^rbvidCT pfbgraiTi 12 ofi a shiailer pdi^olial computer By 
maintaining a user object index at a distribution partner server 1302, the disinbiitibn partner 
server 1302 can also receive and process all acknowledgment message objects used to maintain 
the user object index for any communications object 110. 

10 A third advantage to piroviders is that a distribuitoh service object 13 10 and distribution 

partner server 1302 can provide distribution control capabilities, i.e, the ability to deliver 
customized cpnununications objects 1 10 to consumers; This process is fully explained in the 
distribution control section above. In particular, a distribution service object 1310 can use a data 
exchange method 141 to transmit distribution control methods 141 from a provider program 12 

15 to the distribution partner server 1302. At a distribution partner server 1302, these methods 141 
are called by a distribution service object 1310 or a communications object 110. 

A fourth advantage to providers is that a distribution service object 1 3 1 0 and distribution 
partner server 1 302 can automate archive control, i.e. the ability to retreive previous updates to a 
communications object 1 10. This process is fully described in tiie data archive control section 

20 above. In particular, a distribution service object 1 3 1 0 can use a version monitoring method 1 4 1 
to call a version monitoring meUiod 1 4 1 at tiie distribution partner server 1 302 lo retrieve 
missing updates for all communications objects 1 10 associated with Uie distribution service 
object 1310. 

Distribution services are integral to tiie performance of ahnost any type of partner server 
25 1 302, so it can be desirable to combine them with any of tiie service object types discussed 
herein. 

EnwdinP Service Ohiects and Par tner Server5; 

An encoding service object type (834, FIG. 1 7) can automate the encoding and decoding 
of any type of communications object or communications transmission resulting from a 
10 communications object. Encoding service objects are perhaps the purest example of a 
polymorphic service object because in many forms of cohimunications encckiing, the same 
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algorithm or process used to perform the encoding is used iri feverse to peifoiin' the dsbbding. V :^ 

Because cornmunic^ons partners by nature need to be able to efficiently encode and decode 
^h ptber*^. jdrMBmte shared access to the same encoding service object 1 31 0 is aii ideal 
mecbpism for acconiplishing.tiu^^ Of particular attracttvenesis to providers is the 

5 abU|ty described above for ari encoding service object 1310 to be fetreived from a distribution 
server 32 or encoding partner server 1 302 automaticaHy using the ericodirig service object's link 
coniponem object 1 10. This gives providers a mechanisin to automatically share iwiy desired 
eiicoding/decoding method with any consumer with no effort whatsoever on the consumer's part 
This is especially useful for globally distributing a new encodirig/decoding standard such as a file 

10 format, graphics formal, or encryptions format across a >yide.area network such as the Internet 
Encoding service objects.l3 10 can.supply any of the elements 143 or methods 1 41 
required to perform encoding or decoding operations in the programs 12, 22 or at a partner server 
1 302. The application of encoding and decoding methods in these progriEuhis is iiilly described in 
the encoding control section above. In particular, referring to FIG. 21 illustrating the example of 

IS a word processing file transfer, an encoding service object 1 3 1 0 can be used to perform the 
encoding steps;966, . 967, and.969 and.the decoding stcpsi971, 973, and.974. The appropriate: 
encoding service objects 1310.for each step can be retrieved automatically by the consumer 
program 22 usiiig liiik coniponem objects.l:10.includedJn-the providerfs conmiim^ 
instance 35. 

20 Encoding service objects 1310 can also supply encoding/decoding methods to other 

software programs via an API to the programs 12, 22 as described in the word processing 
transfer example. Using remote procedure calls, such an API could also be extended to rhethods 
stored on an encoding partner server 1 302. 

As explained in the encoding control section above, encoding services in a 
25 corhmunications object system can be applied to any form of encoding. This includes human 
languages, computer languages, object languages, character sets, data file formats, compression 
formats, transmission formats, and encryption formats. The specific encoding service is not a 
limiting feature of the invention. 

Authentication Service Objects and Partner Servers 

30 An authentication service object type (840, FIG. .17) .is a specialized type of encoding 

service object used to authenticate the identity of a communications object provider, consurher. 
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or another service object Authendcation service objects are especially useful in a 
commumcations object system because they can largely automate the process of creating secure 
communications diannels between providers and consumers. 

Many cryptographic protocols have been devised to provide authentication of user 
5 identity and message integrity over data networks. These include Kerberos 5, developed at MIT; 
SPX, developed by Digital Equipment Corporation; Privacy Enhanced Mail (PEM), adopted by 
the Internet Engineering Task Force GETF); Pretty Good Privacy (PGP), developed by Philip 
Zimmermann; and the CCITT X.509 protocols. Such protocols are fully described in the 
aforementioned ApElied Crvptoprpphy by Bruce Schneier. Authentication service objects 1310 
10 and authentication partner servers 1302 can be employed to automate the operation of Aany of 
these protocols. This is accomplished by storing the appropriate encryption keys as elements 143 
and the appropriate encryption functions as methods 141 of the authentication service object 
1310 or authentication partner server 1302. 

An example is authentication using digital signatures based on public/private kfeys. The 
15 first set of steps in this process are shown in FIG. 32A. The process begins widi the provider 
obtaining a suitable authentication service object (1310. FIG. 28) if one is not already present in 
the provider program 12 (step 4101). An authentication service object 1310 contains one or more 
public keys fiom its corresponding amhentication partner server 1 302, stored as elements 1 43. 
TTie authentication service object 1310 also contains the encoding method or methods 141 
20 necessary to carry out its autiientication functions, called authentication methods. When tiie 
provider is ready to create an autiientication account, the provider executes one of the 
authentication metiiods 141 to generate a public/private key pair (step 4102). The private key is 
stored as an element 143 of tiie authentication service object 1 31 0 in tiie provider database 1 1 
(step 4103). Optionally, the data exchange metiiod 141 may also encrypt this private key 
25 element 143 witii a password known only to tiie provider and not stored anywhere in the provider 
database 1 1 or on tiie local computer. The autiientication metiiod 141 next creates an 
autiientication order consisting of tiiree elements: tiie public key generated in step 1402, the 
provider's UID, and a unique registration key known only to tiie provider and tiie autiientication 
partner server 1 302 (step 4104). Otiier elemrats or variables, such as a timestamp, may also be 
30 included. If tiie authentication partner server 1302 is operated in conjunction with a registration 
partner server 1302. tiie unique registration key may be tiie providei's password or otiier 
identification key created at tiie time of registration. This is shown as the Key attribute of tiie 
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system ID instance (251, JIG. 6A). This unique registration key is stored in the provider 
database 1 1 as an encrypted element 143 which can be decrypted using a provider-siipplied 
password. Altemaiively, it may not be stored at all locally but be entered manually by the 
provider when required. The authentication method 141 next encrypts the authentication order 

5 using the authentication partner server's public key (step 4105). The authentication method 141 
then creates a message object 1 10 containing the encypted authentication order (step 41 06). The 
authentication method 141 transmits this message object 110 to the aiithehtication partner server 
1302 (step 4107), The authentication partner server 1302 receives the message object 1 1 0 and 
executes its receipt method 141, which is either the same authentication method or another 

10 authenucation method residing on the authentication partner servier 1302 (step 41 08). This 
authentication method 141 decrypts the authentication order using the authentication partner 
server's private key (step 4109). Next the authentication method 141 verifies the provider's 
imique registration key and UID in the authentication partner serv^ database 1301 to validate the 
authentication order (step 41 10). The authentication method 141 then creates a public key 

IS certificate by combining the provider's public key with certain otfaer.identifying data,^such as the 
provider's UID. (step 4 1 1 1). The authentication mediod J41 digitallyisigns the^public key 
certificate .usmg the authentication partner, server's.private key (step 41 12).. The authentication 
metfaod^Hl then.creates a message;object;HO.containing.the public key certifi^ 4113). 
Finally, the authentication method 141 transmits the message object 1 10 back to.the 

20 authentication service object 1 3 1 0 in the provider program 1 2 (step 4114). There the provider 
program 12 receives the message object 1 10 and executes the original authentication method 141 
in the authentication service object 1310 (step 41 15). This authentication method 141 first 
verifies the signature of the public key certificate using the pubUc key of the authentication 
partner server 1302 (step 4116). Lastiy the authentication metiiod 141 saves the public key 

25 certificate in the provider database 1 1 as an element 143 (step 4117). 

The provider is now leady to digitally sign communications object instances 35 using the 
provider's private key. This process would take place as part of the conmmnications object 
instance generation and transmission routine^ specifically as part of step 548, FIG. 12. The steps 
in this process are illustrated in FIG. 32B. First, an authentication method 141 in the 

30 authentication service object 1310 uses a one-way hash function to generate a hash of the 
communications object markup file (step 4121 ). Next the authentication method 141 uses the 
provider's private key to create a digital signature of tiie hash (step 1462). Finally the digital 
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signature of tbe.markup file together with the provider's public key certificate are appended to 
the markup file before the commumcations object markup file is transmitted (step 1 463). 

The final portion of the authentication process takes place when a comriiuhiciatibns object 
instance 35 bearing a digital signature arrives at a consumer program 22. Thesef steps bccur as 

5 part of the communications object receipt process^ specifically as part of steps 721 or 722, FIG. 
15. The steps in this process are illustrated in FIG. 32C. The process is initiated when a receipt 
method 141 of the communications object instance 35 calls an authentication method 141 in an 
authentication service object] 3 1 0 to verify the digital signature. First, the authentication method 
141 uses the authentication parmer server's public key, stored as an element 143 iii the 

10 authentication service object 1 3 1 0, to verify the digital signiature on the provider's public key 
certificate (step 4131). Since the authentication partner server's private key was used to sign the 
certificatCi only the authentication partner server's public key can be used to verify it. Once the 
public key certificate is authenticated, the authentication method 141 generates a hash of the 
communications object markup file using Hit same one-way hash algorigthm used at the provider 

15 program 12 (step 4132), Finally, the authentication method uses the provider's public key to 
verify the providei^s digital signature of the hash (step 4133); If the results of step 4132 and 1633 
match, the communications object markup file is authenticated, and processing proceeds. 

Other data may be encrypted and signed with the authentication partner server's or 
provider's digital signatures in order to ensure a secure cominunications channel. Such data may 

20 include time/date stamps, the provider's UID or group IDis, random session keys, initialization 
vectors, incremental counters, and so on. Other authentication protocols such as Kerberos. SPX, 
or PEM may also be employed. The specific authentication protocols used are not a limiting 
feature of the invention. Multiple encryption or authentication protocols may also be used by the 
same authentication service object and authentication partner server or by different 

25 authentication service objects and authentication partner servers. The use of additional protocols 
further increases the overall security of the system because the compromise of any single 
protocol does not compromise the security of the entire system. 

Authentication on a communications object system may also take place without using 
centralized authentication partner servers 1 302. This technique, known as distributed key 

30 management is used by the public-domain encryption program Pretty Good Privacy (PGP). It is 
based on the concept of an "introducer". An introdiicer is a person who signs the piiblic key 
certificate of another person whose identity they personally know and are willing to cerUfj-. 
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Intioducers are easily employed on* a communicatiods object system using authentication service 
objects 1310. The steps in the process for using introducers are illustrated in FIG. 33A. First a 
user requring a public key certificate introduction, called the "originator**, executes a data 
exchange method 1 4 1 of an authentication service object 1 3 1 0 to generate a public/private key 
5 pair (step 4151). Next, the data exchange method 141 stores each key as ah element 143 of the 
authentication service object 1310 (step 4152). Then the data exchange method 141 creates a 
public key certificate consisting of the public key element 143 plus such additional elements 143 
as will allow any potential introducer to certify the identify of the orginatbr (step 4153). These 
first three steps can be omitted if the originator only wishes to add uitroducers for an existing 

10 public key certificate already stored as ah element 1 43 of the authentication service object 1310. 
Now, the data exchange method 141 generates an input form prompting the originator for the 
recipients 120 whom the originator wotild like to make introduction requests (step 4154). The 
checkboxes on this input form can represent each of the recipients 120 in the originator's 
consumer database 2 1 , or the originator can specify the e-nunl addresses of still other potential 

15 introducers. The input form also allows the originator to enter the attributes of a message element 
(21 1 » FIG. 4) to be sent to these recipients: When the*input:£Drm is submitted^ the data exchange 
method 141 creates a message object . 110 consisting of the public key certificate, the message 
element,. and.any. other relevant.data, such as a timestamp (step41SS): The.data exchange method 
141 transmits this to all recipients 120 selected by the originator (step 4156). When received by 

20 the recipient's consumer program 22, the message object's receipt method 141 executes the 
recipient's selected notification method or methods 141 for introduction requests (step 4157). If 
distributed key management was implemented on a communications object system, message 
objects containing introduction requests can use a standard notification element type definition 
144. This type definition 144 allows consumers to assign notification methods 141 globally for 

25 all introduction requests, or designate specific notification methods for introduction requests 
from individual recipients 120. When the recipient responds to the notification message, a data 
exchange method 141 in the authentication service object 1310 is executed (step 4158). This data 
exchange method 141 generates a input fomi for confirming the introduction request from the 
originator (step 4159). This input form may include any such data as may be relevant to ah' 

30 introduction request, including the elements 143 of the public key certificate that fiiUy identify 
the originator. The recipient. may also wish to verify the public key with the originator via 
another secure channel, such as via telephone. When the recipient is satisifed that the request is 
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genuine, the recipient submits the input foim (step 4160). The data exchange method 14 1 calls an 
authentication method 141 in the «ithentication service object 1310 which digitidly signs the 
orifpnatQi*s publip key certificate using the redpient's private key (stq».4161). If the recipient's 
private key is storeid as.^ enciypted element 143 of the audientieation semoe object 1310, the 
5 recipisit may ne<^ to mt^ passvi^ord or passphrase for decryption. Then the data exchange 
method 141 creates a message object 1 10 containing the signed public key certificate (step 
4162), The data ^(change mediod 141 transmits this message object 1 10 to the originating 
authenticatipn service object 131Q at the originating consumer program 22 (step 4163). When the 
message object Up is received, the consumer program 22 executes the originating data exchange 
10 method 141 (step .4164). This data exchange method 141 stores the signed public key certificate 
as an element 143 of the authentication service object 1310 (step 4165). Finally, the data 
exchange method .141 executes any notification methods 141 assigned, by the originator to the 
acknowledgment of introduction requests (step 4166). ' 
Once a set of signed public key certificates has been received by the ori^tor. the 
15 originator can send a public key acpeptance request to any other communications object system 
user. The steps in the process for public key certificate accq>tance requests are illustrated in FIG. 
33B. The originator initiates the request by executing a data exchange method 141 of an 
audientieation service object 1310 (step 4181). Thisdata exchange method 141 generates an 
input foim for the acceptance request (step 41 82). This input form can include the attributes of a 
20 • message element (211, FIG. 4) allowing the originator to compose the electronic equivalent of an 
introductory letter. The input form can also allow the originator to cho6se the introducers whose 
public key certificate signatures the originator wishes to present to the recipient. When the input 
form is submitted, the data exchange method 141 creates a message object 1 10 consisting of the 
selected pubUc key certificate signatures, the message element, and any other relevam data, such 
25 as a timestamp (step 41 83). Note that the first two steps above may be oniitted if the acceptance 
request comes directiy fiom another communications object method 141 . In this case the 
recipient of the acceptance request will be specified in the method call, the set of introducer 
signanires can be selected algorithmically, and the message object in step 41 83 can be created 
automatically. Next the message object 1 10 is transmitted to the recipient 120 (step 4184). When 
30 received by the recipient's consumer program 22, the message object's receipt method 141 

executes a data exchange method 141 of an authentication service objea 1310 (step 4185). This 
data exchange metiiod 141 compares the UID of the introducer public key certificate signatures 
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in the message object 1 10 with tiie UID of the trusted pxibKc key certificates stored in the 
recipient's consumer database 21 (step 41 86). These trusted public key ceftii^cates are stored as 
elonents 143 of the authenticatidh service object 1310, and represent introducers whom the 
recipient trusts. For any matching UIDs, the data exchange niethod 141 then calls an 

5 authentication method 141 to verify the introducer signature lisihg the introduber*s public key 
(step 4 1 87). The data exchange method 141 then checks an acceptance request preference 
element 147 in the recipient's consumer database 21 to det^iine if notification is desired (step ' 
4188). For example, notification may not be desired if the signatures of 3 or ndore introducers are 
verified. If notification is desired, the data exchange method 141 executes the assigned 

10 notification methods 1 4 1 to generate a notification message for the recipient (step 41 89). When 
the recipient responds to the notification message, a data exchange method 1 4 1 in the 
authentication service object 13 10 is executed (step 4190). This data exchange method 141 
generates a iiq>ut form for confim:iing the acceptance request from fte originator (step 4191). 
This input form can include the results of the comparison test in step 41 86. It can also include 

15 input fields for a message back to the originator, messages to the introducers, or otiier automated 
options. For puiposes.ofthis:illustration;';we . will assime'the rec^^ 

request. when the input form is submitted (step 4192). (If the recipient denies the request, the 

foUowing.steps.coddproduce a negative:acknowledgment'message.t^ 

exchange method 141 then saves the originator's public key certificate as an element 143 of the 

20 authentication service object 1 310 (step 4 1 93). This now becomes another of the recipients 
trusted public key certificates. The data exchang<: method 141 next creates a message object 110 
containing an acknowledgment of the acceptance request (step 41 94). Optionally, this message 
object 110 could also include a copy of the originatoi^s public key certificate signed by the 
recipient using the recipients private key. The data exchange method 141 transmits this message 

25 object 1 10 to the originating authentication service object 1310 at the originating consumer 
program 22 (step 4195). When the message object 1 1 0 is received, the consumer program 22 
executes the originating data exchange method 141 (step 4196)^ This data exchange method 141 
stores the public key certificate acceptance acknowledgment as an element 143 of the 
authentication service object 1310 (step 4197). Such acceptance acknowledgments can now be 

30 checked automatically by data exchange methods 141 in the consumer program 22. 

Altomatively, if tiie acceptance acknowledgment.included a copy of the originator's piiblic key 
certificate signed by the recipient, this public key certificate could be added to the originator's set 
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pjfinliodiuBeis. Filully the data exdiange meA^ executiss any notification methods 141 
assign^ by the originator to the,»<cIaiowledgment of acceptance requests (step 41 98). 

These public key certificate introduction and acceptance processes can be furither 
impTPY»| by the-use of "trust lev6k".A tnist level is one or more attributes of a public key 
. 5 catificatethat indicate the level of trust the introdudef exteiids to the originator. For exafhple, a 
trust. IcYcl attribiite could accept an integer value range firoiii 1 to 1 0, where 1 eqtisOs the lowest 
level of trust and 10 the highest level. The trust level is part of the public key certificate and is 
signed by the introducer so it cannot be modified by the originator. The truSt level Value can be 
entered by the introducer in step 4 1 59 of FIG. 33A. Trust level values play the satiie role for 
10 public key certificates as threshold values play for notification elements, as explained in the 
notification control section. This means trust levels permit recipients to fiutiiCT automate the - 
processing of acceptance requests and other operations pertaining to secure communiGations. 
This processing would take place in step 4186 of FIG. 33B. By impiementmg atmst rule 140, 
the recipient can determine what trust characteristics would qualify to generate an acceptance 
15 request automatically by the authentication service object 1310 without prior notification to the 
recipient For example, a trust rule 140 could dictate that if an acceptance request had two or 
more verified introducers with trust levels of 8 or greater, an positive acknowledgifteiit would be 
generated automatically. Trust rules 140 could also govern the autoexchange of signed public 
key certificates. For example, a trust rule could dictate that if an acceptance request had three or 
20 more verified mtroducers with trust levels of 9 or greater, the authentication service obgect 1310 
would automatically sign and return a copy of the originator's public key certificate. Trust levels 
are a powerful technique for enabling efficient and effective distributed key management. Trust 
levels can also be used with other communications object system services such as feedback 
services,.as described further below. 

25 Another way authenUcation service objects 1 3 1 0 and authentication partner servers 1 302 

increase the security of a communications object system is by automating key exchange. 
Automated key exchange makes it feasible to use larger keys, to change keys ftequentlyj to 
autoexchange keys among communications partners, to share keys among communications 
groups, and to use specific keys chosen fiom among larger key sets. In particular, authentication 

30 service objects 13 1 0 can use update control to change they public keys they obtain fixjm their 
authentication partner server as frequently as is deemed necessary to maintain adequate security. 
Each update to an authentication service object 1310 can be verified using a digital signature 
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created with the esdsting pid)lic/private as described abcive. Only after the auihenticaltibh 
service object 13 10 has verified the signaliiie of its update va^ it ihhmt its hew public key. This 
capability can be Anther enhanced by the use of acknowledgment control Each authentication 
service object update can include a receipt method 141 that generates a ackiiowledgtneni 

5 message object 1 1 0 back to the authentication partner server 1 302, This adcnowledgmeht 
message object can include a digital signature generated by the new public key. This digital 
signature allows the authentication partner server 1 302 to verify the authenticity of the 
acknowledgment as described above. If the acknowledgment is liot received on a timely basis or 
is not authentic, rules 140 implemented at the authentication partner server 1302 can trigger 

10 notification of the authentication partner server provider. This constant "challenge" technique can 
ensure that authentication service objects. 131 0 are operating correctly thrbiighout a 
ommiunications object syston. 

A final way authentication service objects 1310 can help ensure the security of a 
conmiunications object system is sectirity rules 140. Security rules can monitor all aspects of key 

IS handling and signature verification. Security rules can be paniculariy usefiil for enforcing a 
provider's control over forwarding'^or chairang of the:provider's-communications objects M 0. 
When digital signatures do not nuitch, these rules can automatically trigger notification of the 
user of the programis 12, 22 via any notification method .141 the user desires: These rules can also 
generate message objects 1 10 capable of notifying Ae communications object provider, the 

20 authentication service object provider, and the commimications object system vendor. Since 
authentication service objects play such a central role in the sccmity of a communications object 
system, they can be subject to special rules 140. For example, a rule may require one or more 
authentication service objects 1310 to be included with the programs 12, 22 at all times, or the 
programs will not function. Alternatively, rules 140 may govern the acceptance of authentication 

25 service objects or object updates, for example requiring explicit approval from the user. Another 
approach is the use of a master authentication service object 1 3 1 0 to authenticate all other 
authenucauon service objects 1310. This nwster authentication service object may be a built-in 
system object. It may also use a large public key or keys that are publicly verifiable via other 
. trusted conununications networks such as newspapers or telephones. 

30 Data Exchange Service Ob jects and Partner Servers 

A data exchange service object type (841, FIG. 17) can automate the exchange of data 
with a data exchange partner server 1302. Since commimications objects can include their own 
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daia exchapge methods as described in the data exchange control section above, the primary 
purpose of dateexchange service objects 1310 is to consolidate the data exchange methods 
required by a ^upofcommimications objects, TTjis may be for a single data exc . 
specialized service n^ed shared by a.small group of communications objects from a single 

5 provider, or a common set ofdata exchange services needed shared by a large set of 
. conunvmicatipns objects 60m many [MTovideis. 

An example of the first case is a product registration service object 1310. A software 
company may offer a large number of sofW products, each with its own representative 
communications object 1 10. If the software company wanted all these communications objects to 
10 share the same product registration services for new buyers of tiie company's software products, 

the company could creatp a product registration service object 1 3 1 0. Any of the company's 
product communications objects 1 10 could tiien call tiie services of the product registration 

service object 13 10 to cany out a new user product registration via a product registration partner 
server 1 302. Ideally, such a shared service object would also offer otiier commbn services to the 
15 individual product objects, such as distribmion/updme control, directory sem^ . 
For a communications object system deployed on a wide ai«a network, suteh as the 
Internet, there are a number of common data exchange services desired by niany providers. 
Besides the specialized, services discussed above, examples include file transfer, fax transfer, 
news distribution, discussion databases, knowledgebases, and classified advertising services. In 
20 ntostcasespolymoiphicserviceobjectsl310a«desirablefordataexchange.m 

same data exchange service objects 1310 that aUow communications object system users to 
upload and maintain data at a data exchange partner server 1302 can allow other coihmunications 
object system users to automatically monitor and/or download that data as desired. A simple 
example is an FTP service object 13 10 and an FTP partner server 1302 offered by a provider of 

25 »«^o*filebackupservices.TT,eFITsen.iceobjectl310wouldallowusen.toselect . 
file or files which the FTP service object 1310 would monitor and automatically transfer to the 
FTP partner server 1302 at periodic intervals or when die files had changed. The same FTP 
service object 13 10 could be used to restore backed up files from the FTP parmer server 1302 to 
the user's local system. The FTP service object 1310 could combine these backup services witi, 

30 payment and reporting services. Payment and reporting services are discussed below. 

A more advanced example is classified advenising services. A classified M service object 
niOcombinestiiefunctionsofadataexchangeserviceobject 13 10 and a directory service 
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object 13 10. (It could atso.tncorporate the juhctiibos of ah authentication service object 1 3 1 0; 
payment service object 13 1 0, reporting service object 1 3 1 0, or othw isiich service object 
functions as may be applicable.) A classified i& partner server 130!2 represiehts the categories of 
tiie classified advertising systCT as category objects in the same inaiuief as a directoiy parmer 

5 server 1 302 (nG. 29A), Each of tiiese rategory objects 1 143, 
methods 141, and rules 140 that allows a classified advertiser to define the attributes and values 
of an ad listing in this category. 

The steps involved in the process of a seller using a classified ad service object 1 3 1 0 to 
create an ad listing in a classified ad partoer server database 1301 are shown in FIG. 34 A. 

10 (These closely parallel the steps involved in creating a listing oh a directory partner server 1 302 
shown in FIG. 30.) The process begins witii the seller using his/her browser 50 to navigate tiie 
classified ad partner server 1302. The seller chooses the hyperlink representing the category 
object 1 1 0 in vAAch the provider is interested in niaking an ad listii^ (step 4201 ). The receipt 
method for the category object 1 1 0 first checks to see if its parent classified ad service object 

15 1310 is presentintiie provider database II (step4202).If not, tiie category object uses itslmk 
component object i 10 to download the clasafied ad^serv^ ' 
partner server 1302 (step 4203). The receipt mctiiod 141 then executes a data exchange method 
141 in the.classified:ad.service object:J310; that generates a^^l^ 

input form consists of the category.attribute and: value choices obtained from the category object 
20 110. For example, a category object 1 1 0 such as "Minivan" might generate an input form for 
attributes including make, model, year, color, mileage, condition, and so on. The appropriate 
value choices for each of these attributes would be displayed as drop-down lists, radio buttoiis, 
and so on. When the seller submits the completed input form, the data exchange method 141 
creates a message object 110 containing this input data (step 4205). This message object 1 10 also 
25 contains such other commuiiications object components as are necess2U7 to let prosper 

buyers communicate with the seller. The data exchange method 141 then transmits this message 
object 1 1:0 to tiie classified ad parmer server 1302 (step 4206). When received by the classified 
ad partner.server 1 302, the message object 11 0 mggers a corresponding data exchange method 
. 141 (step 4207). This data exchange method 141 first creates a communications object 110 
30 representing the seller in the classified ad partner.server database 1301 (step 4208). Next the data 
exchange method 141 creates a communications object 1 10 of tiie component object type (812, 
FIG. 17) containing the ad listing element or elements 143 (step 4209). Then the data exchange 
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methpd 141 CTeates niem!bert!ss«aatiOTS llOAbetwe^ 

object 110 and the categpiy composite conununicaUons object 1 10 (step 4210).. In t^^ manner 
the s^ler can stthniit additional ad listii^ widiout needing to duplicate the data in tfie 
com^unicstiofls object 1 1 0 leprosotfiQg the seller. Wh?n this process is completed, the data 
5 ej^hange method 141 creates a message object 1 10 containing an iq>propriate acknowledgment 
.. message (step 421 1). The data exchange method 141 transmits this message object 1 1 0 back to 
the classified ad service object 1310 at the provider program 12 (step 4212)i When received bj' 
the classified ad service object 1310, the message obgect 1 1 0 executes its receipt method 141 . 
(step 421 3). The receipt method 141 executes the seller's desired notification method 141 to 
10 complete the ad listing process (step 4214). This process could also incorporate authentication 
services as described above or payment and reporting services as described below. 

Any interested buyer can use the same classified ad service object 1 3 1 0 and category 
object 1 10 to specify and monitor ad listings that meet the buyer's interests. The steps involved in 
this process are shown in FIG. 34B. (This process is similar to the process of monitoring . 
15 category objects 1 10 on a directory partner server 1302 as shown in FIG. 3 IB.) As with. the ad 
listing process, the monitoring process begins with the buyer using his/her browser 50 to 
navigate the classified ad partner server 1302. The buyer chooses the hyperlink representing the 
category object 1 1 0 in which the buyer is interested in making a purchase (step 4231). The 
receipt method for the category object 1 10 first checks to see if its parem classified ad service 
20 object 1310 is present in the consumer database 1 1 (step 4232). If not, the category object uses 
its link component object 1 10 to download the classified ad service object 1310. from the 
directory partaer server 1302 (step 4233). The receipt method 141 then executes a data exchange 
method 141 in the classified ad service object 1310 that goierates a monitoring input form (step 
4234). The monitoring input fomi is largely identical to the listing mput form described above. It 
25 Aaws some of its attributes and values fiom the category object 1 10. The principle difference is 
that it allows the buyer to specify value ranges or other query formulas for category attributes 
obtained from the category object 1 10. To use the automobile example above, a "Minivan" 
wtegory object might use drop-down list of integer values for the "Not oldc^ than" year attribute; 
use checkboxes for muhiple color choices; accept an integer value for "maximum mileage"; use 
30 radio bunons for acceptible condition attributes; and so on. When the form is submined. the data 
exchange method 141 first saves the input form data as a query element 143 (step 4235). 
Secondly it creates one or more scheduled evem instances 1 1 7 in the consumer database 1 1 (step 
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4236). These sdieduled event instances !17 can begin inunbdiately and repeat at intervab or 
according to rules 140 specifiiid by the consumefr on the inpiit fdnh. They can also be subject to 
monitoring rules 140 imposed by the clasafied ad service provider in the category object 1 10 or 
classified ad service object 1310. When activated, these scheduled event instances execute a data 

5 exdiange method 141 in the classified ad service object 1310 (step 4237). The data exchange 
niethod 141 then creates a message object 1 10 containing the ad query (step 4238). The data 
exdiange method 141 transmits this message object 1 10 to the classified ad partner server 1302 
(step 4239). When received by the classified ad partner server 1302, the message object 110 
triggers a corresponding data exchange method 141 (step 4240). This data exchange method 141 

10 uses the ad query to to query the classified ad pahner server database 1301 for any ad listings 
satisfying the query (step 4241). the data exchange method 141 then returns the result set to the 
consumer program 12 (step 4242). If there are no ad listings that satisfy the query, the resuh set 
is a message object 1 10 reporting this. If there are ad listings that satify the query, the result set 
arc the communications objects 1 1 0 representing the seller together with the component object 

15 110 representing the seller's ad listing. This is advantageous because these commiinications 
objects 1 10 enable the buyer and seller to-inunediately establish.^A^^ 
relationship to consummate the sale. After the consumer program 22 receives the result set, it 
executes any receipi:mcthods4)ertaining;to the 

notification test (step 4244): If the there were no matching ads, the buyer may not desire 
20 notification. If tiiere are matching ads, the buyer may desire different notification based upon the 
attributes values of the matching ads. For example, if a mini van meeting the buyer's query was 
listed at a price below a certain value, the buyer might desire to be paged immediately, whereas 
at a higher price the buyer may only wish to receive notification in the buyer's notification report 
(630, FIG. 1 3). The provider program 12 then executes any desired notification metiiods (step 
25 4245). Again, this process could also incorporate authentication, payment, reporting, or other 
service object services. 

The above classified ad monitoring process operates by storing and executing the 
classified ad query at the consumer program 22. In the same fashion that it can be more efficient 
to monitor a high-volume directory partner SCTver 1 302 using a user object mdex, it can be more 
30 efficient to monitor a high-volume classified ad partner server 1 302 using a user object index tiiai 
includes the buyer's stored queries. TUs also allows queiy result sets to be transmitted to to 
buyers via the push technique, as opposed to the pull technique illustrated above. The steps for 
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implementing mooitgrii^ with a user object index with stored queries at a partner server are 
shown in FIG. 35, The first step is identical to step 4235 of FIG. 34B. where the data exchange 
method 141 oftheclasafied ad service object 13 10 saves the input, form data as a query element 
or elements, 143 (step4261). The data exchange method 141 then creates a message object 110 
5 containing the query element or elem^ts 143 {stap 4262); This message object 1 10 also contains 
9»ch other conununications object conoponents as are necessaiy to create a user object 110 
rq)resenting the buyer. This in^li^ a dau exchange method 1 4 1 for processing result sets 
produced at the classified ad partner server 1302. The data exchange method 141 of the classified 
ad service object 1310 next teansmits this message object 1 10 to the classified ad partner server 
10 1302 (step 4263). When received by the classified ad parmer server 1302, the message object 
1,10 triggers a corresponding data exchange method 141 (step 4264). This data exchange method 
141 first creates a user object 1 10 representing the buyer in the classified ad partner server 
database 1301 (step 4265). Next the data exchange method 141 creates a communications object 
1 1 0 of die component object type (8 12, FIG. 1 7) containing the ad query elemem or elements 
15 143 (step4266). This component object 1 10 is given a member association 11 OA with die - 
buyer's composite communications object 1 10 (step 4267). In this manner the buyer can submit 
additional ad queries without needing to duplicate the user object 1 10 representing the buyer. 
User objects 1 1 0 and ad query component objects 1 10 can also be indexed for performance 
optimization. Next the data exchange method 141 uses the query elements 143 of the ad query 
20 componem object 1 10 to create one or more scheduled event instances 1 1 7 in the classified ad 
partner server database 1301 (step 4268). As with stored queries in the.consumer program 22. 
these scheduled event instances 1 17 can begin immediately and repeat at intervals or according 
to rules 140 specified by the consumer or the chissified ad service provider. When activated, 
these scheduled event instances execute a data exchange method 141 on the classified ad partner 
25 server 1302 (step 4269). This data exchange method 141 dien executes the ad query (step 4270). 
When the query result set is returned, the data exchange method 141 calls another data exchange 
raethod.l4l in the buyer user, object 1 10 (step 4271). The buyer's data exchange method 141 
processes the result set to determine if notificauon is desired by the buyer (step 4272). If so, the 
buyer's data exchange method 141 calls a data exchange method 141 in the classified ad partner 
30 swver 1302 (step 4273), This data exchange method 141 creates a message object 1 10 containing 
the result set (step 4274) and transmits it to the consumer program 22 (step 4275). There the 
consumer program 22 receives the message.object 1 10 and executes its receipt method 141 (step 
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4276). The consusner prdgrdni 22 then executes any notificattoh methods 141 specified tHe 
buyer to control notification abbut classifed ad queries (stqp 4277). 

The data exchange procedures illustrated here for sellers and buyers using a classified 
sendee object 1310 to iautomate interchange with a classified advertising database 1301 stored on 

5 a classified ad pautner seiveaf 1 302 can be geheralijid to any type of data that can be stored in a 
s^ver database miiiiially accessible to providers arid cohstuhers on a conmiunications network 3. 
This includes search services, news services, document retreival services, knowledgebases, 
discussion databases, and so on. The specific type of database, database server, or data exchange 
service is hot a limiting feature of the invention. The only differences are the organi2ation and 

lb formaLt of the data stored oh the server database and the queries and rules used to automate 
information interchange. These generalized steps are summarized in FIG. 36. The first step is to 
use composite and component communicaticms object types (811,812, FIG. 17) to represent 
organizational or topic structure in the data exchange partner server database 130i (step 4291). 
This creates a metadata structure for the data stored in the database. Category objects discussed 

15 above and shown in FIG. 29A arc one example of such a metadata structure. A second example 
is shown in FIG. 29B. This illustrates how composite ahd:component conununic^ objects 
can be organized as the main topic and response "threads'* in a message database, discussion 
database; or knowiedgebase.'The main lopicis a composite'conm type 145 1 . 

Each response to this main topic is shown as a fust-level response thread object 1461', 1 462. 

20 Each response to a first-level response is shown as a second-level response thread object 1 47 h 
1472, 1473, 1474. Just as software object relationships can be used generally to model many 
real-world relationships, the association and aggregation relationships (shown in FIGS. 3 and 4) 
between composite and component conununications objects can be used generally to model 
many metadata relationships. The first advantage to using conununications objects 110 to 

25 represent the metadata structure of a partner server 1 302 is that the structure is dynamic. 
Communications objects 1 10 can be added, deleted, and edited easily. Secondly, when these 
changes lake place to the metadata stmcmre, every provider and consumer affected by the change 
is updated and notified automatically. 

Referring back to FIG. 36, the second step is to use conamunications object type 

30 definitions 1 44 and elements 1 43 to model the data and metadata stored within the larger 
metadata structures on the partner seiVer (step 4292). the use oiFtype definitions 144 and 
elements 143 to model data and metadata is explained in multiple sections above. A specific 
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example is the use of ne^^c^jipu elements and message elements (201, 21 1, FIG. 4) as discussed 
in the notification control section above. Again, the use of software objects allows such . 
modelling to be appUed broadjy to njany real-world database needs. The third step is to use data 
exchange servic? objects 1 3 1 0 ai!4 in«$sage fibje^as 1 1 Q to automate data exchange between the 
3 programs 12. 22 and the dat^..expj;i^ge piirtner sarya 1 302 (s|ep 4293). As exphuned throughout 
this section and the data «xph»Qg^. control section, a combination of data exchange methods 141, 
^ data exchaoge rules 140. and dsta exchange elements 143 can be u&ed to automate many kinds of 
data uploading and updating for providers and data monitctoing, querying, and downloading for 

consumers. The fourth step is using luser object indexes representing the providers and 
10 consumers interacting with the data exchange partner server 1302 whenever traiisfening 
processing tasks from the programs 12. 22 to the partner server wiU increase data exchange or 
network efficiency (step 4294). This procedure is explained in the service object introduction 
section, tiie directory service object section, die distribution service object section, and illustrated 
in detail in tiiis section and HG. 34B. In particular, it allows data updates or query result sets to 
15 be transmitted via the push technique when it is more efficient than the pull technique. The fifth 
step is to use data exchange methods 141 and notification control at the programs 12, 22 to 
process message objects and query result sets (step 4295). This is shown in the fmal steps of 
FIGS. 34A, 34B, and 35. This allows providers and consumers to realize the maximize benefit of 
data exchange automation by not being notified of anytiiing but the most highly relevant - 
20 information, and tijen having complete control over tiie notification metiiod. The sixtii step is. 
returning communications objects 1 10 in query result sets whenever it would increase tiie 
efficiency of data exchange or communications for tiie user (step 4296). This is illustrated in step 
4242 of FIG. 34B, where tiie seller's communications object 1 10 is remmed togetiier with tiie 
seller's ad listing. This technique is particularly powerfiil when tiie communications object 1 10 
25 returned is a category object 1 1 0 or a service object 1 3 1 0 or granting tfie user access to a new set 
of communications objects 1 10 or partaer servers 1302. The final step is using link control in 
commmiications objects 1 10 and category objects 1 10 to simplify and automate access to service 
objects 1302 and otfier category objects 110. This is discussed in tiie service object introduction 
section and tiie directory service object section. This technique spreads linking intelligence witii 
30 ^ weiy communications object 110 in a communications object system, making it as easy as 
possible for tiie users to gain access to tiie services of any type of partner server 1 302. 

Payment Service Ohiftrtc a^r ^ Partner Serv>^^ 
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A paym^t service object type (S42;nG; 17) is a sp^alized data exchange ^ 
object that operates in conjunction with payment paitner sefvears 1 302 id provide secure financial 
transaction services to providers and consmners. A payment swvice object 1310 may combine 
the functions of a data exchange service object 1310 with those of an authentication service 
5 object 1310, or it may call the services of a separate authentication service object 1310, (The 
examples in this section will use the laittef technique:) Payment service objects allow such 
common payment services as credit card transactions, debit card transactions, electronic funds 
transfers, and cybercash transactions to take place easily, automatically^ and securely in a 
conununications object system. 

10 The following explams the basic processes involved with the use of payment service 

objects 1310 and piayment partner servers 1 302. These are broken into several sets as shown in 
FIGS; 37, 38, and 39. The st^ in the fmicess of a merchant creating a payihent account are 
illustrated in FIG. 37. The process begins with the merchant obtaining a copy of the payment 
service object 13 10 if one is not already present in the provider database 1 1 (step 4401). When 

IS the merchant is ready to use the payihent service object 1 3 1 0 to set up a payment account, the 
merchant activates^' data exchange method 1 41 in the paynient service object 1310 (step 4402). 
This data exchange method 141 first generates a public/private key pair, either itself or by calling 
the seryicesiof an authentication service object 1310 (step 4403). Alternatively the data exchange 
method'141 can use an existing public/private key pair available fiom the authentication service 

20 object 1310. The private key is stored as an element 143 of the payment service object 13 1 0 in 
the provider database 1 1 (step 4404). As with an authentication private key, this key may also be 
encrypted with a password known only to the user and not stored locally. The data exchange 
method 141 then queries the provider database 1 1 for the elements 143 necessary to create a 
payment account (step 4405). This process is explained in the data exchange control section. 

25 Because many of these elements 1 43 are commonly required items of data, such as the provider's 
name, contact data, financial account data, credit references, and so on, they will already be 
present in the provider database 1 1 and can be automatically accessed by the payment service 
object 1310. The data exchange method 141 then generates an account data input form (step 
4406). The purpose of this form, as with most data exchange input forms, is threefold. First, it 

30 allows the merchant to confinn any data exchange rules 1 40 the merchant may have applied to 
the transfer of the merchant's sensitive financial data, such as bank account numbers or credit 
references. Second, it allows the merchant to confum the accuracy of any other data to be 
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transfrired, sudi as contact data. Third, it allows the merchant to enter any specific new data 
required by the payment service provider. As explained in the data exchange coiitrol section, 
such new dat? can also be saved as elements in the provider database 1 1 for future use. When the 
merchant submits the cpnjpleted input form, the data exchange method 141 creates a account 
5 order (step. 440^. The payment service object 1310 thencaUs an authenticafioti method 141 in 
an authentication service oljjdcl 1310 to encrypt the accbuntoider tising the payment partner 
seiver's public key, stored in the payment service object 1310 as ah element 143 (step 4408). The 
authenU.q9tion method 141 then digitally signs the account order using the merchant's private key 
(step 4409). The merchant's private key may be stored in the authentication service object 1310 
as an encrypted element 143, in which case the authentication method 141 may first require a 
password from the merchant for dectyption. Alternatively the merchant's private key may be 
entered manually in some other way. The data exchange method 141 now creates a message 
object 1 1 0 containing the secure account order and the merchant's public key certificate, stored 
as an element 143 in the authentication service object 1310 (step 4410). Optionally this message 
15 object 1 10 may also contain such data as is necessary to create a user object 1 10 representing the 
merchant at the payment partner server 1302. The data exchange method 141 transmits this 
message object 110 to the payment partner server 1302 (step 4411). The payment partner server 
1302 receives the message object 1 10 and executes a data exchange receipt method 141 (step 
4412). This data exchange method 141 calls the same authentication service object 1310 to 
20 d««^iypt the secure account order using the payment partner server's private key, stored as an 
element 143 in the partner server database 1301 (step 44 13). Next the authenticaUon service 
object 1310 verifies the merchant's public key certificate signature using the authentication . 
partner server's public key, stored in the authentication service object 1310 as an element 143 
(Step 4414). Finally the authentication service object 1310 verifies the merchant's signature on 

25 theaccountorderusingthemerchant'spublickey(step4415).Nowthedataexchangeme^ 
141 on the paymwit partner server 1302 can execute whatever steps are necessary to use the 
account,order to create a merchant account (step 4416). In a preferred embodiment, the merchant 
account would be represented by a user object 1 10 in the payment partner server database.1301 . 
When finished, the data exchange method 141 creates a merchant account certificate coiisisting 

30 o|.the merchant's account number, the merchant's provider UID, and whatever other dat^ 

payment service provider wishes to include in the certificate, such as a timestamp. account type 

identifiers, payment partner server identifiers, and so on (step 4417). (The merchant account 
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at'the payment partner server.) The data exctbange method 141 then callis an autbendcitioh' ' 
method 141 in the authentication service object 1310 to digitally sign the mmhaht account 
certificate using the payment partner server's private key (step 4418). Next the data exchange 

5 method 141 creates a message object 1 10 containing the sigr^ merchant account certificate 
(step 4419). The data exchange method 141 transmits this mesisage object 110 back to the 
payment service object 1310 in the merchants providier program 12 (step 4420). There the 
provider program 12 receives the message object 1 1 0 and executeis the original data exchange 
method 141 of the payment service object 1310 (step 4421). This daita exchange method 141 first 

10 calls an authentication method 1 4 1 in the authentication service object 1 3 1 0 to verify the 

signature of the merchant account certificiate using the payment partner server's public key (step 
4422): Then the data exchange method 1 4 1 stores the m^hant account certificate in the 
provider database 11 as an element 143 of the payment service object 1310 (step 4423). Lastly 
the data exchange method 141 calls any notification methods desired by the merchant for 

15 notification of the merchant account certificate receipt (step 4424). This comipietes the process of 
setting tq) a secure paymentraccountfor the'raerchantv. ' 

To begin using this account with customers, the merchant includes thie merchant account 
certificate and a link-component object 11 0 from the payment service object 1310 in any 
communications'object 1 10 where the merchant wishes to use payment services. The payment 

20 service object 1310 can then be called by any data exchange method 141 in the merchant's 
communications object 1 10. The merchant can indicate the services of such payment service 
objects 1310 by using the names or logos of the appropriate credit cards, debit cards, and so on in 
a product ordering input form, for example. When a customer chooses one of these options and 
submits a data exchange input form, the payment service object 1310 is used automatically. The 

25 steps in this process are shown in FIG. 38. First the data exchange method 1 4 1 creates a purchase 
order consisting of the data from the input form together with the merchant account certificate 
(step 4441). Next the data exchai^e method 141 queries to see if the payment service object 
1 3 10 is present in the customer's consimier database 2 1 (step 4442). If not, the data exchange 
method 141 uses the payment service object's link component object 1 10 to download the 

30 payment service object 1310 (step 4443). The payment service object's receipt method 1 4 1 will 
then initiate the process to create a cuistonier aiccduht (step 4444)! This process is identical to the 
merchant payment account creation process shown in FIG. 37, except the final resuh is that the 
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customer is issued a custQmw account ccrtifi^ ^ .^ 

elemenj 143 of the payment service object l-S lD. If the payment service object 1310 WaS present 
intheconsunierdatabase21 in step 4441,the data exchange method 141 calls a version 
nrwnitoriog method 141 to see if the vcraion is cun«it (stq, 4445). This versidii mohitbiing 
5 method 141 coi5paissiJ!eveBioiivalueofthepaymem.sem 
, value stoi«l in the link component object 110 of thcmerchant's communication 
Version monijpring is explained in the dato .^c^ange contn,! section above. If the version is not 
cimoit. the data exchange method 141 executes the update method 141 ofthepayment service 
object 1310 to download the cunent vasion (step 4456). Once the current version of the payment 
10 .s^i^eobjectJ310isp«sentintheconsumerdatt^ 

merchant's conununications object 110 calls a data exchange method 141 in the paymem service 
object 1310tq.continuethetiansaction(step4457).Thisdataexchangemethod 141 callsan 
authentication method 141 in an authentication service object 1310 to enco'pt the purchase order 
using the payment partner server's public key. stored in the payment service object as an element 
15 143 (step 4458). The authentication method 141 also digitally signs the purchase order using the 
customer account certificate private key (step 4459). As described above, this key may be stored 
as an encrypted element 141 in the payment service object 1310 and require a password fh,m the 
customer to decrypt. AltemaUvely the customermay supply the key manually in some other way 
Next the data exchange method 141 creates a message object 1 10 containing the secure purchase 
20 order and the customer account certificate (step 4460). The data exchange method 141 transmits 
this message object 110 to the payment partner server 1302 (step 4461).nre paymempartner 
server 1302 receives the message object 1 10 and executes its receipt method 141,which is either 
the same data exchange method 141 or another data exchange method 141 residing on the 
payment partner server 1302 (step 4462). This data exchange method 141 calls an authenUcation 
25 method 141 in the authentication service object 1310 .to yerify the customers signature on the 
secure purchase order using the customer account certificate public key (step 4463) Next the 
authentication method 141 decrypts the purchase order using the paymem panner server's private 
key (step 4464). Finally the amhentication method 141 verifies ti,e merchant's signature on the 
merchant account certificate using th. payment partner servers private key (step 4465). Now a 
30 d^t««changem^odl41onthepaymentpartnerserverl302cancarTyoutthep^^^ 
transaction usir« the verified purchase order data, the verfied customer account certificate, and 
the verified men:hant account certificate (step 4466). This may involve any sequence of steps 
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between ihe payment partner server 1302^ and odier payment servos or data processingv systems, 
such as the consumer's iiank orcredit cleartn^iise; a credit C£Utl processor, a cybercash server, 
and so on. Whoi the transaction has be« complied, the data exchange method 141 creates a 
unique receipt number stored as an element 143 m the payment pairtiier server database 1301 

S (step 4467). This receipt nimiber can now be used to verify tliie tiiinsadiion with both the 
customer and the merchant; 

From this point the receipt ackhowledgihent process can take several paths. The payment 
partner server 1302 can return receipt acknowledgments to both the consumer program 22 and 
the provider prograni 12. Each of these programs can in turn send receipt acknowledgments to 

10 the other to cbn^Iete fiill three*way acknowledgment Alternatively the payment parmer server 
1 302 can send a receipft iacknowledgment to the customer's consmner program 22, which can in 
turn send a receipt acknowledgment to the merchant's provider program 12, or vice versa. In all 
cases the steps in sending secure receipt acknowledgment messages are similar. The steps m the 
process of the payment pahiier server 1302 sending a receipt acknowledgmmt niessage to the 

IS customer's consume program 22 are shovm in FIG. 39. First a data exchange method 1 4 1 on the 
payment parmer serveri 302 creates a pimchase receipt (step 4471). The purchase receipt 
includes the unique receipt number plus any other relevant d^ta, such as timestamp, the payment 
partneryserver UID,.baiik certification numbers^ and so on. Next the.data exchange method 141 
calls an authentication method 141 in m authenticadon service object 1310 to encrypt the 

20 purchase receipt using the customer account certificate public key (step 4472). This step is 
optional if the purchase receipt does not contain any sensitive information. The authentication 
method 141 then signs the purchase receipt with the payment partner server's private key (step 
4473). The data exchange method 141 creates a message object 1 10 containing the purchase 
receipt (step 4474). The data exchange method 141 transmits this message object 1 10 to the 

25 payment service object 1 3 1 0 at the consimicr program 22 (step 4475). There the consumer 

program 12 receives the message object 1 10 and executes the original data exchange method 141 
of the payment service object 1310 (step 4476). This data exchange method 141 first calls an 
authentication method 141 in the authentication service object 1310 to verify the signature on the 
. purchaise receipt using the payment partner server's public key (step 4477). If the purchase 

SO receipt hais bfeen encrypted, the authentication method 141 decrypts it using the customer account 
certificate private key (step 4478). Then the data exchange method 141 stores the purchase 
receipt in the consumer database 21 as an elerhent 143 of the payment service object 1310 (step 
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4479), This-makps the purchase receipt: avaUable to the payment service olqfect 1310 and the 
merchant commimications object 1 10 for use insany further transactions or coiTCsiiondehce 
involviiig this transactioii,,Such a$ a retum or exchange. Finally the data exchange method 1 4 1 
executes any notification mediofts 141 desired by the customer for notification about the receipt 
5 acknovrledgmient (step 4480), 

This ^chnique can be generalized to any form of data exchange requiring secure, 
verifiable, non-nspudiable transactions between multiple parties. This includes stock trading, 
electronic data interchange (EDI), credit card.systems, banking systems. barteHng systems, and 
so on. The specific nature of the transaction service is not a limiting feature of the invention. 

10 Reporting Service Ohiects «^ Partner .^SBrygrff 

A reporti^ service object type (843, FIG. 1 7) is another specialized data exchange 
service object that operates in conjunction with reporting partner servers 1 302 to provide 
statistical reports on the usage of a communications object system. Since communications 
objects 1 10 can include their own reporting methods 141 as described in the reporting control. 
15 section above, the primary purpose of reporting service objects 1 3 1 0 is to consolidate the 
reporting methods required by a group of communications objects 110. 

Shared access to the methods 141 of a reporting service object 13 10 is particularly 
efficient for gathering statistics and metadata for a large population of communications objects 
no. This is because statistics and metadata for a large number communications objects 1 10 from 
20 a large number of providers can accumulated in the databases 1 1, 21 and then transmitted using a 
snaall number of message objects 110 to one or mo«5 reporting partner servers 1302. The same 
reporting service object 13 10 or a linked reporting service object 1310 can then be used by tiie 
providers to monitor the aggregated reports at the reporting partner server 1302. This can be done 
using data exchange methods 141 running queries against a reporting partner server 1302 in the 
25 same fashion as explained in nGS.34B and 35 for classified ad buyers. 

.Reportiiig partner servers 1 302 can also serve a valuable function by providing high- 
volume report processing services to communications object providers. Report processing 
methods 141 on tiie reporting partner server 1302 can be triggered automatically by nsport 
message objects 110 transmitted from reporting service objects 1310. These report processing 
30 methods 141 can produce any type of statistical aggregation or analysis offered by the reporting 
service provider. Aitematively. communications object providers can use the reporting service 
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object 1310 to submit thdr awB Stottd^q)^^ 141 as 

explained in no,. 35 for classified ad buyers. . 

Anonymous lepbrti^g i>Blattdnslups can be accompli^ed using a isimple procedure. The 
steps in this process are shown in FIG. 40. The process begins wh€?n a rqwrtlng service object 

5 1310 first needs to set up an anonymous reporting relationship with a reporting partner server 
1 302, A data exchange method 1 41 in the reporting sCTvice bbject: 1 3 10 uses an anonymous 
protocol such as HTTP to request an anonymous reporting key bom a reporting pkrtner server 
1302 (step 4501). The reporting partner server 1302 returns an unique anonymous reporting key 
in the protocol response (step 4502), The data exchange method 141 then saves the aik>nymous 

10 reporting key as an element 143 of the reportmg service object 1310 (step 4503). If desired, such 
an element 143 can also be enciypted using a password or similar key provided by the user. 
From this point on the reporting service object 1310-can supply the anonymous reporting key 
together with Ae report data when submitting rqwrts via the anonymous protocol to the 
reporting partner server 1302 (step 4504). In this fashion Ae reporting partner server 1 302 can 

15 track the report data submitted bom a unique instance of the reporting service object 1310 
without havingany knowledge of the uscrfsidentity (step .4505). 

Reporting partner servers 1 302 can aggregate reporting data by indexing reports by 
provider UID or consumer lJID,,or in the case ofanonymousreporting^by unique anonymous 
reporting'key. Alternatively reporting partner servers 1 302 can use the incremental counter 

20 technique. This technique is explained below in the section on feedback service objects. 

Secure reporting can be accomplished using the functions of an authentication service 
object 13 10 in conjunction with a reporting service object 1310. Reporting service objects can 
also be efficiently coupled with payment service objects to perform billing and payment for 
" communications object system services. 

25 Feedback Ser vice Objects and Partner Servers 

A feedback service object type (844, FIG. 17) is another specialized data exchange 
service object that works in conjunction vAih a feedback partner server 1 302 to aggregate and 
report feedback from users of any communications object 1 10 across a conmiunications object 
system. Feedback seryice objects 1310 combine the functions of directory service objects, data 

30 exchange seryice objects, and. reporting service objects to aggregate feedback from multiple 
communications object system users across different categories of communications objects 1 1 0. 
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Feedback service objects 1310 are^otlier exoeUent exanq>le of a polymoifphic service object 
because the sa^ie feedback service object 1310 that is used to provide feedbjick ifrom one 
communications object system user (called the "feedbadc provider'') can be used to access or 
monitor, tiial fe^hack by another communications object system wser.(called the "feedback 
5 consum^")^ 

Feedback service ottjeets 13 1 0 Oaii m6st easily be understood as an ej^tension* to the 
fimctiohality of^categoty objects 110. Category objects 1 10 are explained m the director' service 
object s9ctio^ above and shown in FIG. 29 A. In particular, communications objects 1 1 0 listed in 
a directory, partner server 1302 can indirfe a link component object 110 to each category object 
10 no with whichthe communications object 1 10 is associated. This allows users of a 
communications object system to quickly and easily obtain category objects 110 to check 
directory partner servers 1 302 for other communications objects 1 1 0 associated with the category 
object 1 10. This process extended into a poweriy feedback system with three enhanceiriehts. 
First, feedback attributes and value choices can be added to category objects 110. This permits 
15 users of a communications object 11 0 can be solicited for feedback specific to that particular 
category of communications objects 1 10. Second, report processing capabUhes can be added to 
directory partner servers 1 302. This permits feedback data to be aggregated into reports of high 
value to communications object system users. Third, the feedback attributes of the category 
objects 110 can be used by feedback consumers to create queries to a feedback partner server 
20 1302. This aUows feedback consumers to be automatically notified of new or changed 
communications objects 1 1 0 that meet the user's specific interest criteria. 

The steps in these processes are very similar to those described for classified ad category 
objects in the data exchange service object secdon above and in FIGS. 34A, 34B, and 35. The 
following explains the basic processes involved with the use of feedback sendee objects 1310 
25 and feedback partner servers 1302. Both the feedback provider and feedback consumer will be 
illustrated as users of the consumer program 22. The steps in the process of a feedback provider 
submitting feedback input are illustrated in FIG. 41 A. We will assume the feedback provider 
already has obtained the communications object 1 10 upon which the feedback will be given. The 
process begins with the feedback provider executing a feedback link method 141 in the 
30 communications .object 1 10 (step 4601). The presence of a feedback link method 141 for 

feedback can be shown by the use of a feedback hyperlink or hypergraphic on a page 142 of the 
communications object 1 1 0. Alternatively, if feedback services are implemented as a global 
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fimcdoh of a commumcatiom object systeni, this feedback tink method 141 can be available as a 
syston method 141 to all comihiimcatiohs objects' 1 10. In this case feedback services cbiild be 
initiated through a feedback hyperlink or hypergraphic on the selected objeiit form (611, FIG. 
13), on any selected page foim (612, FIG. 13), or on a global toolbar in the consumer program 

5 22. Once executed, the feedback link method 141 queries the consumer database 21 for the 
tmked feedback categoiy object 1 1 0 (step 4602). If the link method 141 is linked to more than 
one feedback category object 1 10, the link method 141 can present tKfe feedback provider with an 
input foim to. ^lect the desired fe^back category object 1 1 0. If the feedback category object 1 1 0 
is not present, the link method 141 uses link control to download die feedback category object 

iO 1 10 (step 4603). Next a link method 141 inthe feedback category object 1 10 queries the 

consumer database 2 1 for the linked feedback service object 1310 (step 4604). If the feedback 
\- sennce object 1310 is not present, the link meftod 141 uses link control to download the 
feedback service object 1310 (step 4605). Now a data ^change method 141 in the feedback 
service object 1310 gmerates a feedback iiq>ut form (step 4606). TUs input form consists of the 

15 category attribute and value choices obtamed from the feedback category object 1 1 0. This is 

identical to the input formprooess!described in step of of FIG/34A for creating a . classified . 
ad listing. The feedback attributes and value choices for any feedback category object 1 10 are 
determined by the feedback service-provider: To continue /the:example:used in the classified ad 
service description, the feedback input form for a feedback category object 1 10 representing 

20 miruvans might include attributes for dealer satisfaction, fit and finish, gas mileage, maintenance 
costs, repurchase plans, and so on. The appropriate value choices for each of these attributes 
would be displayed as drop-down lists, radio buttons, and so on. When the feedback provider 
submits the completed input form, the data exchange method 141 first saves the feedback data as 
a feedback element 143 of the feedback service object 1310 (step 4607). This permits the 

25 feedback provider to easily recall and modify the feedback data as his/her feedback changes. 
. Next the data exchange method 141 creates a message object 1 10 containing the feedback data 
from the input fomi and the UID of the target communications object 1 10 (step 4608). The data 
exchange method 141 then transmits this message object 1 10 to the feedback partner server 1302 
(step 4609). When received by the feedback paimer server 1302, the message object 1 10 triggers 

30 a corresponding data exchange method 141. (step 46 10). This data exchange method 141 can 
aggregate and process tfie feedback data- in the feedback partner server database. 1301 as . - 
proscribed by the feedback serve provider (step 461 1 ). Feedback data aggregation and processing 
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is described below. The data ipxchange mediod 141 can fliso.pi^]tfonn any Icirid of ag'gi^egation or 
statijrtical analysis r^uirtKi to produce the reports tt^ feedback sendee provider wishes^ tp offer 
feedback consumers. The attribytes of these reppits must match the, feedback report query 
attributes of a feedback categpjy o^yept 110 as de$cribf?d below, 
5 Feedback^data can be aggregated by a feedback partner server 1302 in several wiys. One 

aHijrpach is to save and index feedback data by the UID of the feedback provider. In this 
qjproach the feedback partner server 1 302 maintaios records of the feedback data from each 
feedback provider. This allows the feedback partner server 1302 to produce accurate feedback 
statistics reports over time. Another approach is to aggregate feedback using counters. In this 
10 approach the feedback partner server 1 302 does not need to maintain a record from each 
feedback provider. Instead the feedback partner server 1 302 increments a counter for each 
feedback message object 1 1 0 received from a feedback provider. The accuracy of this counter is 
maintained in the following manner. The first time a feedback provider uses a feedback category 
object 110 to send feedback data, the full set of feedback data is transmitted in the feedback 
15 message object 1 1 0 as described in step 4608 of FIG. 41 A. This feedback data is saved as an 
element 143 of the feedback category object 1 10 the consumer database 21 as described in step 
4607 of FIG. 41 A. The steps required for subsequent changes to the feedback are shown m FIG. 
41B. First the feedback provider executes the feedback luik method 141 as in step 4601 of FIG. 
4 1 A (step 463 1). Because the feedback provider has aheady submitted feedback, the feedback 
20 category object 1 1 0 and feedback service object 1 3 1 0 are present in the consumer database 2 1 . 
Thus the feedback link method 141 can directly execute a data exchange method 141 of the 
feedback service object 1310 (step 4632). This data exchange method 141 reads the saved 
feedback clement 143 of the feedback category object 1 10 (step 4633), The data exchange 
method 1 41 uses this feedback data to generate an mput form for the feedback provider to edit 
25 the feedback data.((siep 4634). When this input form is submitted, the data exchange method 141 
saves the new feedback data as a new version of the feedback element 143 (step 4635). Versions 
of the feedback data element can be controlled using data archive control as explained above. 
The data exchange method 141 next calculates the differentials between the new feedback data 
and the old feedback data (step 4636). For example, a minivan owner originally rated dealer 
30 sen^ice at an 8 on.a scale of 1 to 1 0. The minivan owner subsequently had a poor dealer. service 
experience. The minivan owner then edits the feedback data to rate the dealer service at a 2. The 
data exchange method 141 would calculate the differential as a minus 6. Now the data exchange 
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niethbd 141 t^reaxiss a ine^ssage object 1 16 contfiiming di^ ielKibaick diffi^ d^i^ the TJID of 
the tsqget c^miniM 10, ahcl a "Rih/is^h«" i^ldm^^ 143 set to lTiU^ <step ' 

4637): The data exclUhge meti 141 transmits thb messa Ae feedb^bk partner 

server 1302 (step 4638). When received by the'feedbkck partner server 1302, the ihesiiage object 

5 1 10 triggers a corresponding data exchange method 14 ! (step 4639). This datai exchange method 
141 uses the value of the RevisedFiag element 143 to process the fe^back data as incremental 
data and not new data. The data exchange method 141 then uses tiie difieietitials in ^e feedback 
data to adjust the feedback counters (step 4640). Revised feedback data will not increment ai 
"Total Feedback Providers" counter, so feedback consumers can see an accurate report at of the 

10 total aggregated feedback at any point in time and the total liumber of feedback providefrs who 
have contributed to this feedback data. Feedback data counters allow the maintenance of 
feedback data to be distributed throughout a cbmmiimcadbns objec^ system, making it feasible to 
centrally aggregate feedback for a large ntimber of communications objects 1 10 from a latgb 
population of feedback providers. Feedback data counters also xiiake it easy to do anonymous 

IS reporting, as no provider UIDs must be tracked at the reporting partner server 1 302. 

Alternatively; if feedback data is saved and indexed^ at the reporting partner^server* 1302;*.*: 
anonymous reporting can be accomplished using the anonymous reporting key technique as 
described in the reporting service object section above and illustrated in FIGr40. 

The steps in the process of a feedback consumer accessing and monitoring feedback are 

20 identical to those of a classified ad buyer accessing and monitoring classified ad listings as 

explained in the data exchange service object above and illustrated in FIGS. 34B and 35. As with 
directory category objects 110, a feedback consumer can obtain a feedback category objeict 1 10 
either directly from a feedback partner server 1302 or by using a link component object 1 10 in 
any communications object 1 10 associated with that feedback category object 1 10. 

25 ' The value of feedback data can vary enormously with the experience and expertise of the 
feedback provider, this is particularly true for feedback on topics requiring specialized 
knoWledige or expertise, such as academics, law, medicine; technology, and so on. For this reason 
feedback services can also be applied to feedback providers. This can be accomplished using a 
feedback partner server 1302 by linking feedback category objects 1 10 to user objects 1 10 

30 r^resentihg each of the feedback providers. The attributes of a feedback category object 1 10 
rq)resentii^ a feedbaick provider might include level of expiertise", level of credibility, level of 
decision-miaking ability, and so on: By aggregating feedback data on feedback providers, a 
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fepdb^^. i^i^ server 13,Q2 is able to offer even more usefii] feedback reports to feedback 
consumers, ijiiis is ^«$muse feedback queries can seleict: feedback data using on the attributes or 
"ratings" of the feedback providers. An example is a feedback partner server 1302 which collects 
feedback data on conmiimications objects 1 10 repiie^ting automohil^. A feedback consumer 
5 can create a quf^f for onjy th^M cpinmunicatiqins objects 1 1 0 repiqienting raimyans with a 
sticker price of less than $2p,(p winch also had ovenill quality rating of 7 or higher on a scale 
of 1 to 10 from l^baek providers whb?«. expertise level was rated by other, feedback providers 
to also 7 or higher on a scale of 1 to 10. Another example applies to response thread objects 
(FIG. 29B) in a topic discussion database. Here a feedback Consumer can use a topic feedback 
10 category object I JO to monitor the response thread objects 110 contained by a discussion topic 
no. A query can notify the feedback consumer only of new response thread objects posted by 
providers with aij expertise rating of 7 or higher on a scale of 1 to 10. A feedback consumer can 
also ask for feedback provider ratings to be factored into feedback data repons. An example 
would be a report on recommended minivans where the feedback data from feedback providers 
15 with an expertise rating of 8 or higher on a scale of 1 to 10 was weighted twice as heavUy as 
feedback data from feedback providers with a raUng lower than 8. 

The integrity of such a feedback system can be enforced by employing feedback rules 
140 in the feedback partner server 1 302. For instance, a feedback rule 140 can constrain the 
rating a first feedback provider can give a second feedback provider using the rating of the first 
20 feedback provider. An example would be a expertise rating system for securities analysts. Every 
analyst in a securities analysis firm can be given an initial expertise rating on a scale of 1 to 1 0 
for each feedback category object 1 1 0 representing the industiy segments covered by the analysis 
firm. Thereafter all analysts can modify the expertise ratings of the other analysts as new security 
analysis work is performed. A feedback rule 140 can enforce that a first analyst camiot give a 
is setend analyst an^xpertise rating for a specific feedback category object 1 10 more than 1 point 
higher than &e expertise rating of the first analyst on that same feedback category object 1 10. A 
second/eedback rule 140 can specify that no analyst can change the feedback rating of another 
analyst more than 1 point in any six month period. These rules help enforce accurate expertise 
appraisals. 

30 The integrity of such a feedback system can also be enforced through the use of 

authentication services to authenticate the identity of the feedback providers as .described in the 
authentication service object section above. Feedback systems may also incorporate payment 
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services as described in the payment service object section above. An example would be a ? 
conmiercial product rating; service that paid industry experts for feedback input and charged 
. corisuiners for feedbs^k r^^ 

As' with dirtScidry services, feedback services can be employed for a wide variety of 
5 purposes bii a communicatidns object system; This includes product and service rating services, 
political office ratic^^t etiaployee peifoimahce feedback, discussion group participation, personal 
references, and so oh. The particiilair feedback service is not a limiting feature of the invention. 

AT^VAKCKD SYRTF.M Aj^rHTTRCTl JRE 

Conibiried ProVidfer. Consumer, and Server Program Oberation 

10 It hias been explained how in an embodiment of the present invention the functions of the 

provider and consumer programs 12, 22 and databases 1 1 , 21 can be combined because they use 
identical database structures and similar operations. In another embodiment of the present 
invention, the functions of either or both the programs 12, 22 and databases 1 1, 21 can be 
combined with a partner server 1 302 and a partner server database 1 301 . This is again because 

15 identical database structures and similair operations are used. AU programs can: also employ the 
same HTML and HTTP interface operations as described above. This means that a 
communications object system user may fully access the capabilities of a provider program 12, a 
consumer program 22, and a partner server 1 302 all firdm a' single web s«ver 32 using a single 
web browser 50. 

20 One of the additional benefits of combining the provider program 1 2 with a distribution 

server 32 is that providers do not have to transmit new and updated commimications objects 1 1 0 
to a separate distribution server 32 for distribution via the pull technique. Nor do they require the 
services of a distribution service object 1310. Rather pull updating from a consumer program 22 
can take place directiy firom the combined provider program 12 and partner server 1302. This 

25 saves time and reduces the potential for transmission errors. A provider is also able to more 
easily apply distribution control by speciiying distribution control methods 141 directiy in the 
combined database 1 00. 

The same benefit applies in reverse to consumers when the consumer program 22 is 
combined witfi a distribution partner server 32. The consumer program 22 does not need to 

30 update communications objects 1 10 stored on tiie distribution parmer server 1302 using the pull 
technique because those communications objects or object updates 1 10 can be pushed directly by 



BNSOOCID: ^WO_e73a2S1Al_l_> 



-173- 

provider Brpgram 1 2 to the combined consumer prpgrain 1 2 and. j^artaw server 1 3 02. This 
also e)ii7^iiK||tes.th« pieed fpr a disjtribttt^^ 

These benefits are fiuthaxompounded when both the fwovider program 12 and consumer 
prppaiR H j^e combiijfid wi4 amy type of distribution server 31 This combination of yields 
5 special. b^NSt? fcr multiuser communications object «^stem installations in the same way as 
combining the functionality of the programs. 12, 22 yielded special benefits fbr a^ingle 
communi^pos,.object system user. Thesi? benefits will be further described in the following 
sections.. 

Multiuser Operation 

10 Tiie programs 12, 22, and 1302 or any combmation thereof can accommodate multiuser 

opexiBtio». Iii aill cases this can be accdinplished by employing the user object type (8 1 6, FIG. 
17). The data fractures for user objects 1 10 are shovra in FIG. 6B. Like all other 
communications objects 1 10. user objects 1 10 have a system ID attribute that uniquely idemifies 
them vwthiii the database 100. The provider and consumer relationship between user objects 1 10 

15 and other communications objects 110 uses a relationship association class 1 11 of the association 
1 lOA. One attribute of the relationship class 1 1 1 is a logical value "ProviderFlag". If a user is a 
provider of a communications object 1 10, the ProviderFlag value is TRUE. If the ProviderFlag 
value is FALSE, the user is a consumer of the communications object 1 10. The relationship class 
1 1 1 also has an attribute NewFlag which is employed in user object indexes as described above. 
20 The relationship class 1 1 1 may have other attributes such as "PrivilegeUvel" that govern access 
control to operations such as editing tiie communications object, forwarding the communications 
object, and so on. Access control will be discussed below. 

User objects 1 10 can represent individual communications object system useis or groups 
of users. User group objects 1 10 function smiilariy to e-mail aliases in an e-mail system. Groups 
25 can be nested by creating composite user objects 1 10 and components user objects 110. User 
group objects 1 10 can also have their own distinct attributes used to control the communications 
functions and privileges of the group. 

Multiuser operation is beneficial in tiie programs 12, 22 or a program combining tiieir 
operation because it aUows a single database 100 to be shared by multiple users. A separate 
30 instance of the global preferences class 1 03 can be associated with each user object 1 1 0. In a 
multiuser database 100, multiple user objects 1 10 can have a consumer relationship association 
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1 1 1 with single inStaicc of commimca&ons object 1 16- tliis saves disk spaed ind increases l 
overal] system efficiency. In tfiis case each ransinnier can maintain separate preferences using 
separate element preferences instances 147 associated with the consumer's uscJr object 1 10. Users 
can also shaie preferences by having an association to the same element preference instance 1 47. 
5 Access control rules 140 can be iised to go Verri editing rights to shared elemenC^feichce 
instances 147. Acceiss control rulcis will be discussed below. 

In a multiuser d^biase 100, a user object 1 10 can have a consumer relationship with a 
communications object 1 10 to which another user object 1 10 has a provider relationship. This 
has several very important benefits. To begin with, no instance of the recipiOTt class 120 nor the 
10 acknowledgement association 121 is needed. Both can be replaced entirely by the relationship 
associations 111. Secondly, no conununications object distribution routine is necessary. When 
the user object 1 1 0 repr^ntmg a provider (called the "provider user object") and the user object 
110 represendng a consumer (called the "consumer user object") are both present in a multiuser 
database 100. a communications object 1 10 can be "pushed" to a consumer simply by the 
15 provider creating a new association between the communications object 1 1 0 and the consumer 
user object 1 10. A communications object 1 1 0 can be "pulled" by a consumer just by the 
consumer creating a new association between the communications object 1 1 0 and tiie consumer 
user object 1 10. In both of tfiese cases, creation of the new association-triggers.a "new object 
reception rule" 140 in the database 100. This rule takes the place of the new object reception 
20 routine in a separate consumer progranni 22 and executes steps 703 - 708 of FIG. 1 5. Updates to a 
commuiucations object 1 10 by the provider can also be "transmitted" to all associated consumers 
via the operation of the standard update association rule 140 operating throughout the database 
100. This operation of this rule takes the place of the update object reception routine (FIG. lOB) 
by executing steps 721 - 73 1 of FIG. 15. This rule 1 40 only applies to consumer relationship 
25 associations, i.e. where the ProviderFlag.value is FALSE. 

Finally, in a multiuser database 100, multiple user objects 1 10 can also have a provider 
relationship with a single communications object 110. This is referred to as multiuser editing. 
Multiuser editing of communications objects 1 1 0 is advantageous in a conununications object 
system for the same reasons multiuser database sharing is advantageous *m many business 
30 applications. Just as two or more individuals ean need the ability to read or edit same data, two or 
more individuals can n^ to conuhunicate about the same subject or topic through the same 
"channel". In many midtiuser database environments, including network file systems, database 
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access aiid editing rights aie contrqiled u$ing access control lists. This same principli^ (m be 
ai^lied to^ a (X>minuiucatiQns object system through the lise of access control elemenUs 143, 
access control mediods 1 4 1^ and access cozitrol rules, 1 43,. Collectively these are referred to as 
acgi^ contrpl coB)iponentj5,,^ccess contipl eli?inem 143 are/special elements 143 included in a 
5 cpmmui«$iaj$pns object 1 lQ,in order to defti^ the editingdghts. which original 

compiun^c^pjtis object provider wshes to graiit to other provideis. Access control methods 141 
and aooes^ (jsptrol rules 140 act in conjunction with Access control elements 143 to ehfoi'ce these 
rights. Access qontrol is an extension of data exdumge controU discussed in the data exchange 
control section above. Access control components ate a unique advantage of a communications 
10 object system because they can be contained within the communications object 1 10 which they 
govern. Thus they can be. distributed and enforced throughout a communications object system. 
Access control rights can also be governed using user group objects 1 1 0. In this capacity user 
group objects 1 10 function similarly to access control groups iised in many computer network 
environments to govern file and resource access. 
15 As in any multiuser database, simultaneous editirig of the same data field or record by 

diflferent users can resuh in conflicts * Many multiuser databa^ record locking or data conflict 
resolution techniques have been developed to solve this problem, including rules based on time 
precedence, user priority, location priority, data types, and so on. This is referred to as 
concurrency control. In a multiuser communications object system database. 100, concurrency 
20 control can be applied using concurrency elements 143, concurrency methods 141, and 

concurrency rules 140. Collectively these are referred to as concurrency control coinponents. 
Concurrency confrol can be applied in one or more conununications object system databases 100 
in the same manner as access control. The specific concurrency control rides or techniques 
employed are not a limiting feature of the invention. 
25 In a communications object system, multiuser editing applies to three situations. The first 

is single users operating different single-user installations of the combined programs 1 2, 22 on 
different computers 1, 2, The second is.dififerent users operating the same multiuser installation 
of the combined program 12, 22. This could be on a single central computer accessible over a 
local area network^.or on a distributed database available over a wide area network. The third is a 
30 combination of the^rst two; In the first situation, multiple users can edit the same 

communications object 1 1 0 through the use of message objects 1 \ 0. The basic steps involved 
with this form of multiuser editing are illustrated in FIG. 42A: The process begins with the first 
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provider <^f a communications' object M-0 speci^^ the access control the provider wishes to ^1 
apply to a coxmnuiiicationsi>bject 1 10 (step 4701). This is doiiel^ 'Specifying access odhtrol 
components and choosing ^propriate access cbhtrdi valueis. Next thefirst provider tn^^its the 
conomunications object 110 to a recij$ieiit (step 4702). The consumer prbgrain 22 of the jieciptenl 
5 receives the. conmiunicationi object 1 .1 0 sand sioies it in biis/hef consumer da^a^bkse 2 1 (step 
- 4703); The recipient next pafoite ah editing operiaiibri oii the commtinic^bife 1 10 (step 
4704). These editing operations will be constrained by the access cohirol components of the 
communications object 1 1 0, For example, the provider of a comraunicatibns objwrt 110 
represoiting a discussion topic ihay grant recipients the right to add response thread objects 1 10 

10 representing responses, such as is shown in FIG; 29B. However this provider may not grant 
recipients the right to edit the naine; description, or message in the original topic object 1 1 0. The 
-completion of an editing operation by the recipient triggers a data exchange control nile 140 
which executes a data exchange method 141 of the communications object 1 10 (step 4705). In 
this way the data exchange control lule 140 serves the same purix)se as the tqidate association 

15 rule 140 in a database 100. The data exchange method 141 creates a message object 1 10 

containing the changes tto the.conununications object 4 10 (step 4706); The data exchange method 
141 then transmits th^ message object 1 10 to the combined program 12, 22 of the first provider 
(step 4707). When the message .object 1 10 is received, its receipt method 141 is executed (step 
4708). The receipt method 141 saves the edits to the communications object 1 10 (step 4709). 

20 Conflicts in edits by two or more users are handled by concurrency control as discussed above. 
This save operation results in the same set of operations as an edh operation in the provider 
program 12 as shown in FIGS. 1 OA and lOB. These changes will now be distributed to all 
recipients of the communications object 1 1 0 using distribution control as described in the 
distribution control section above. Lastly, the receipt method 141 executes any notification 

25 methods 141 assigned by the first provider (step 4710). 

This procedure centralizes distribution control at the original communications object 
provider! An alternative is distributed distribution control. In this technique, a distribution 
control list is included with the communications object 1 1 0 itself Distribution control lists 
. operate for a communications object .1 10 siniilarly to the recipient list of an Internet SMTP e- 

30 mail message. . E-mail recipient lists allow each. message xecipient to- identify the other recipients 
and send message replies to all other recipients. Like access control lists, distribution control lists 
can consist of distribution control elements 143; distribution control methods 141, and 
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distribution cbntrol rules 140. Collectively &ese are referr^ to as distribution control * 
componrats. Distribution control tu>mponents c^^ 143 
containing the UIDs of each recipient 120. In this case tiie receiving program 12, 22 Avould 
resolve these UIDs into the e-mml addresses or other addresses of the.recipients. Alternatively 
5 distribution control components can include instances of recipient objects. 1 20 or user objects 
1 1 0. in this case the necessary di^bution control intelligence is transferred entirely ^vith the 
communications 'object 1 10. Distribution control methods 141 and rules 140: can be applied at 
each combined program 12, 22 receiving the conunuhicatipns object 1 10, For example^ a 
distribution control rule 140 from the original provider could specify that no additional recipients 

10 may be added to^a distribution control list. Another distribution control rule could specify that 
certain edits to the communications object, such as a change in a notification element, are sent 
only to the original provider. The original provider can then approve the edit and distribute the 
change to the rest of the distribution control list 

The steps involved with multiuser editing using distribution control components are 

15 . shown in FIG. 42B: The process begins with the first provider of a communications object 1 1 0 
J specifying both the access control and the distribution control the provider wishes to apply to a 

conmiunications object 1 1 0 (step 473 1 ). This is done by specifying access control components 
and values and distribution control components and values. Next the first provider transmits the 
communications object 110 to the recipients on the distribution control list (step 4732). The, 

20 consumer program 22 of the recipient receives tiie communications object 1 1 0 and stores it in 
his/her consumer database 21 (step 4733). The recipients next performs an editing operation on 
the communications object 1 10 (step 4734). The completion of an editing operation by a 
recipient triggers a data exchange control riile 140 which executes a data exchange method 141 
of the communications object 1 1 0 (step 473S). The data exchange method 1 4 1 creates a message 

25 object 1 1 0 containing the changes to the communications object 1 1 0 (step 4736). The data 
exchange method 141 then transmits the message object 1 10 to each of the recipients on the 
distribution control list (step 4737). When the message object 810 is received by each recipient, 
its receipt method 141 is executed (step 4738). The receipt method 141 saves the edits to the 
communicationsiobject 1 10 (step 4739). Conflicts in edits by two or more users are handled by 

30 concurrency, control as discussed above. This save operation results in the same set of operations 
as an edit operation in the provider program 12 as shown in FIG. lOA. However, because the 
changes have already been distributed to the distribution control list, this is an exception to the 
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iqxlate association rule 140 and does nottrigger the.c^xiate association routine shown in FIG. 
lOB. Lastly, the receipt method 141 scecutes any. notification ineiho^^ assigned, .by each 
recipient (stq) 4740). 

The sfscond multiuser editing situation applies when the conibined programs 12, 22 are 

5 operated as a niiUtiuser sysieih and &e prdviders and consumers involved are all iisers of this 
system. In this caSe miiltiu^r editing operates in the saime ihanhor ks record sharing in a typical 
multiuser database environment. E^h coixununicatidhs object 1 10 is a recdrd created by the first 
pr6vider in the database 100, and the access control components of the communications object 
1 1 0 act as the acceiss control rights for other users of the database 1 00. In a multiuser database 

10 100, access control rights can also be governed by the attributeis of a relationship association 
(111, FIG. 6B). In this manner a provider can grant different access control rights to different 
user objects 1 1 0 or user group objects 110 representing other providers. Distribution control 
within a multiuser database 1 00 is not necessary because, as explained above, distribution in a 
shared database 100 is accomplished through the operation of the update association rule 140. 

IS The third multiuser editing situation is a combination of the fist two, i.e. users spread 

across'both single-user installations and multiuser installations of the programs 12, 22. This 
operates as a special case of the first situation. In this case, distribution control lists can contain 
special entries representing multiple users at a multiuser installation. These special entries can 
consist of nested elements 143 representing the UID of the multiuser database 100 and the UIDs 

20 of each individual user object 1 1 0. Alternatively they can contain nested composite and 

component objects 1 10 representing the multiuser program 12, 22 and the individual user objects 
1 10< User group objects 1 10 can also be employed for this purpose. In this manner only one 
conununications object or communications object update transmission heeds to take place to 
each multiuser database 100. The receipt method 141 of the communications object 1 10 or 

25 message object 1 1 0 can then create or update the relationship associations 1 1 1 to each user 
object 1 1 0 in the multiuser database 1 00. 

A multiuser commimicatibns object system can be applied to solving many longstanding 
conuntmications problems. A conmion example is many-to-many messaging among large 
groups. One existing solution to this problem is e-mail list servers, or "listservs", which are 

30 common on the Internet. Listservs require a great deal of effort to setup, configure, and maintdn. 
Listscrvs typically operate in three modes which must be carefully configured in the listserv 
program. The first mode is "closed" or "broadcast only", in which messages can only be sent out 
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MO the list subscribers, usually by one or more "list Qvwiers^\ The^SQCond mode is "moderated", in 
which list subscribers can reply to mc^ge^ or submit new messages, but all messages pass 
through one or more moderators authorized to seleci those that will be passed on to the.full list. 
The third mode is "opoi" or "unmoderated", in. which mqnbe^ <:aij resppnd to jtn^sssiges sent 
5 out to the list or submit new mess^gcss, and all me^es, qr tepUe§,are sent tq all subscriber. The 
single biggest drawback to any qf thjese modc^ is tbe;sub$cribei's inability to filter the messages 
on the list for those of personal relevance. The list is eitiier "on" or "off for all subscribers. The 
use of closed or moderated listsCTvs offers soine uspftil filtering capability applicable to, all 
subscribers to tiie list, but this filtering is not personalized for individual subscribers. It also takes 
a great deal of effort on the part of the moderators. 

A comrnunications object system overcomes all these limitations. First, in a 
communications object system, such a mailing list can be created simply by creating a 
communications object 1 10 to represent the list. No special server program or complex 
configuration is required. Secondly, this mailing Ust object 1 10 can employ notification control 
to allow every member of the list to filter messages on the list. As shown in FIG. 4 arid explained 
in the notification control section, this is done by including a set of notification elements 201 
representing interest topics. One or more message elements 21 1 are associated with one or more 
notification elements 20 1 . Each list member can choose the set of interest topics to which they 
wish to "subscribe". Thereafter in each communications object update the list member will 
receive notification only of the messages assigned to these topics as described in the notification 
control section above. The work of one or more moderatois is still required to create and 
periodically refine this set of interest topics, but this small effort produces an very large benefit 
to the entire audience. Thirdly, the operation of the mailing list can be controlled using access 
control components and a distribution control components, A closed Ust can be maintained by 
restricting editing rights to tiie the provider as list owner. A moderated list can be maintained by 
giving all members message editing rights, but keeping distribution control centralized at tiie list 
owner and employing a moderator rule 140 tiiat each new message 21 1 must be confiimed by tiie 
list owner. An open list can be created by eliminating tiie moderator rule 140, A ftiUy distributed 
list, in which tiie processor workload for sending out new messages is disuibuted equally among 
all list contributes ratiier tiian centralized at one provider, can be accomplished using a 
distribution control list. 
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Multinetwork GortiTnunicafions CQntml- 

Beciuise a commiimoatiotis obj system permits providers and consumers to control any 
type of commiihicatidns over any type df communications network 3, it can be particularly useful 
for CQl&rdinatihg cbmmuiiicatidns relationships that take place over multiple communications 

5 networks. A smijAt example is a Iriterhrt-based fex request system. Such a system allows users 
to reqii^ falx dociffcients Using a web server SO and have them trahsmitt^ to the user as fax 
ddcimiehts via a telq)hone rietworL Siich a system can easily be automated using 
communications object system. This can be accomplished using data exchange methods 141 
included directly in a communications object 1 10, or it can be done using a data exchange 

10 service object 1310. The latter permits fex services to easily be shared among many 

communications objects 1 1 0. The steps for automating a fax request sysitem using a fax service 
object 1 310 are shown in FIG. 43. The process begins with the consumer obtaining tfie 
communications object 1 1 0 offering &x request services (step 4801 ). Next the consumer selects 
the hyperlink or hypergraphic representing a fax request page within the communications object 

IS 110 (step 4802). This executes a link method 1 41 which checks to see if the linked fax service 
object 1310 is presOTt in the consimer databa^ not, it uses link control to 

download thefsuc service object 1310 (step 48M^^ in the fax 

service object 13 10. generates an input:foim:(step 4805): This input. form allows the.consumer to 
select the fex'documents the consumer^ would like to receive as well as the target fax number. 

20 Note that the fax service object 1310 can query the consumer database 21 for elements 143 vrfth 
a type definition 144 of "FaxNumbcr" in order to automatically present such a list. The fax 
service object 1310 can also prompt the user to enter new fax numbers if none are present When 
the consumer submits the input form (step 4806), the data exchange method 141 first saves any 
new fax number elements 143 as well as the consumer's preferences about the last-used fax 

25 number, the most-used fax number, and so on (step 4807). The data exchange method 141 then 
creates a message object 1 10 (step 4808). This message object 110 contains the indentification 
data for the requested fax documents (which could be the UIDs of the fax documents if they are 
stored as elements 143 on the fax partner server 1302). The messiage object 1 10 also contains the 
. . selected fax number. The data exchange method 141 transmits the message object 1 10 tb.tiie fax 

30 partner server 1302 (step 4809). When the message object 1 10 is received by tiie fax partner 
server 1302, it executes a corresponding data exchange method 141 (step 4810).'This data 
exchange method 1 4 1 uses the fax request IDs and fex number to transmit the requested fax 
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docimj^t$ via the telephone network (step 481 1). Npte that if the fax partner server 1 302 cannot 
sjuccessfiilly transmit the fax documents, the fax partner server 1302 can also send an 
acknowledgment message object 1 1 0 back to the consumer via the communications object 
system, 

5 A more cmiplex example is the'cdordination of package^deliveries over a physical 

commimications network finicjh as a postal network. This process uses accouiit certificates as 
described in the payment service object section. The steps in this process aire shown in FlG. 44. 
The process begins with the consumer obtaining the communications object 1 10 of thei package 
recipient (step 4901). Next the consumer selects a hyperlink or hypergraphic representing a 
physical package delivery option vnthin the communications object 110 (step 4902). Such an 
option might be represented by hypergraphics of the logos of coriimon delivery services. This 
executes a link method 141 v^ch checks to see if the linked physical delivery service object 
1 3 1 0 is present in the consximer database 2 1 (step 4903), If not, it uses link control to download 
the physical delivery service object 1310 (step 4904). Next a data exchange method 141 in the 
physical delivery service object 1310 generates an input form (step 4905). This input form allows 
the consumer to select the desired delivery options. This includes the type of delivery required, 
whether delivery pickup is needed, payment options, and so on. Note that the consumer does not 
need to enter any infoimadon pertaining to the delivery attributes of the recipient The data 
exchange method 1 41 is able to obtain all such attributes from the account certificate included in 
the recipient's communications object 110. If the consumer also has a account certificate, the data 
exchange method 141 can use this data automatically as well. If the consumer does not have an 
account certificate, the data exchange method 141 can use the input form to prompt the consumer 
for the necessary account information. When the corisumer submits the input form (step 4906), 
the data exchange method 141 saves any new account data or preferences as elements 143 of the 
physical delivery service object 1310 (step 4907). The data exchange method 141 then creates a 
message object 1 10 containing the recipient account certificate, the sender account certificate, the 
delivery options selected, and any other pertinent data, such as a timestamp (step 4908). The data 
exchange method 141 transmits the message object 1 10 to the physical delivery partner server 
1302 (step 4909). When received by the physical delivery partner server 1302, the message 
object 1 10 executes a corresponding data exchange method 141. (step 4910). This data Exchange 
method 141 processes die delivery order (step 49 11). This can mclude obtaining a delivery 
number, initiating the package delivery pickup by the physical deliverj' service provider, and any 



«732251A1 I > 



.182- 

other steps riisceSsaiy to initiate the aelivery. When coinplete; the data exchai^e miiiifabd 141 
creates a acknowledgment message dqect 110 contmtiihg the delivery number together with any 
other ackriowledgment data, such as flie delivery pickup cohfinriatioh message (step 49 1 2). The 
data exchax^e method 141 transmits this message object 1 10 to the physical delivery service 
5 object 1 3 1 0 at the originating consumer program 22 (step 491 3). When recei at thle consumer 
program 22, the message object 1 10 executes the originating dati exchange method 1 4 1 of the 
physical delivery service object 1310 (step 4914). Tlie data exchange method 141 first saves the 
delivery number and any other pertinent data as logged event 1 1 8 (step 49 1 5): This allows it to 
be referenced for any future actions involving this delivery: Next the data exchange method 141 

10 executes any notification methods 1 41 assigned by the consumer to delivery acknowledgment 
messages (step 491 6). The data exchange method 141 then calls a print method 141 to imnt a 
deliveiy label (step 49 1 7). The data exchange method 141 tests to see if delivery monitoring was 
requested in by the input form submitted m step 4906 (stq> 4918). If so, the da^ exchange 
method 141 cairies out the monitoring process (step 4919). This monitoring process iis identical 

15 to that performed by classified ad service objects 1310 as shown in FIG. 34B. Alternately, if the 
physical.delivery:partnenserverul302.offers:monitorihgy^^^^ - 
queriesftfaenecessary user object data and query data.can also be contained in themessctge object 
1 10 created Jn step 4910. Monitoring.using stored-queriesis showniin E^ 

Another example of multinetwork communicatiom control is the reception 

20 conununications objects or object updates via a broadcast network such as television or cable 
systems. Because such networks are broadcast-only, communications resulting from the 
consumer's communications object copies back to the provider must occur via a backchannel 
such as a telephone network or computer network, e.g. the Internet. Conununicatlons objects 
represent a unique advantage in this respect in that the backchannel can be controlled by the 

25 provider in the conuntmications object 1 10. In addition, multiple backchannels can be controlled 
by the same communications object 110 depending on the communications action involved or 
the backchannel capabilities of the particular consmner program 22 where the communications 
object 110 is stored. 

Schedyig rpntrol 

30 Schedule coordination among any group is a fundamental challenge in communications. 

Scheduled events and schedule changes must be communicated to everyone in the group or else 
the group will not function. A communications object system can solve many widespread 
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. scheduling prpblems using a special type of communications object called a schedule object. 
Schedule objects aresho>VD as class 817 Qf FIG. 17; Schedule objects 110 represent real^world 
events associated with any other communications object 1 10. Like all othei;.conmiunications 
object^ 1 10, sclu^ule objects 1 jl.O cpn cohjtain sche^uif^ elements 143, schedule: mpthcKls44l/w^ 
5 schedule rules 140 used to control scheduling pp^iations, Coliecdvely are refiBgnreiclito as 
schedule control componi^ts. These all funotiQn as speciid cases of data exchange control, 
discussed above. Schedule objects 1 10 can also be nested as composite and contpoiietit objects 
(8 1 1 , 1 82, FIG. 1 7). This, permits a composite sche4ule object 1 1 0 to contain nmltiple 
component schedule objects 1 1 0. An example would be a composite schedule object representing 
10 a multi-day conference, with component schedule objects representing the mdiyidual seminars at 
the conference. Like any communications object 1 10, schedule objects 1 10 can be distributed via 
push and pull and contain their own update methods. This is particularly relevant to schedule 
coordination because any changes to a schedule object 1 10 can be transmitted to all consumers 
associated with that schedule object 1 10 object. Using notification control, each user can also 
15 control exactly how he/she is notified of these changes. Schedule objects 110 can be maintained 
in any database 100, whether single-user or multiuser. Schedule objects 1 10 are particularly 
usefiil for managing group schedules in a multiuser database 1 00. This is because schedule 
objects 1 10 can easily be associated with user objects 110 or user group objects 1 10 to create and 
maintain scheduling relationship associations 111. Alternatively, communications object system 
20 programs can handle scheduling requests through an API with an external scheduling program or 
database. A communications object system API is discussed further below. 

One of the most effective uses of schedule objects . 1 1 0. is to constrain or modify the 
conununications c^abilities of communications object 1 10 or user objects 110 used to represent 
individuals. For example, an individual whose current schedule object indicates they are at lunch 
may be reachable via a cellular phone but not via e-mail. This can be accomplished using 
scheduling rules 140 associated with particular elements 143 and methods 141 in a . 
comn^unications object 110. For example, a scheduling rule may dictate that after business hours 
important phone calls should be directed to a provider's home phone number. The use of ^ 
scheduling objects 1 10 and schedule control allows communications objects 1 10 to assimie the * 
same functions of "universal phone numbers", also called "personal numbers", "lifetime 
numbers", and "follow me numbers". The difference is that universal phone numbers apply only 
to telephone communications and are limited to the capabilities of a particular telephone 
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net^worki whereas <kmiinunicatioQS objeMStsr 1 10 apply to every fonn of comiriuhications and are 
not limited to the c£q;)id>iiities of any^^ 

Schedule objects 1 10 can be eihplbyed to solve a wide vairiety of common scheduling 
prdblems. Ond example is the uhiversd problem of *^teiephohe tag*\ In this example, schedule 

5 objects 1 1 0 are employed ait a distfibutibh seiver 32: Any type of distribution server 32 can be 
used, but' iii a preferred embodiriibnt, a coiiibuiatidn of the programs 1 2, 22 and a distribution 
partner server 1302 is used. This allows message objects 1 10 to be transmitted and received 
directly from the distribution piatner server 1302 using a direct transmission protocol such as 
HTTP. This is fester than a store-and-fonvard protocol like Internet SMTP e-mail, however the 

10 latter can also be used if the scheduling proems is not time-s^itive. To enable telephone call 
coordination, the provider first adds one or more scheduling elanehts 143, methods 141 , and 
rules 140 to any communications object 1 10 in which the provider wishes to offer scheduling 
control. The provider can also add schedule control using a sdieduling component object 110. 
The provider also maintains his/her current schedule by adding and maintaining schedule objects 

15 110 to the provider database 1 1 . Thus the provider's current set of schedule objects 1 10 will 
indicate the^present readiness of the provider to'receivea^phone call; the ciirrent phone numberat 
which the provider should be reached; the options for notifying the provider about the caU 
request; and.the options for scheduling a phone call with the.provider^at some future time if the 
provider, is not available inunediately. v 

20 ThiE^ steps in the process of a consumer contacting a provider to request a phone call using 

the provider's communications object 1 10 are illustrated in FIG. 45. The consumer first executes 
a hyperlink or hypergraphic representing a voice call request on on a page within the provider's 
communications object 1 10 (step 5001). This executes a scheduling method 141 which creates a 
message object 1 10 containing the voice call request (step 5002). This request can include the 

25 name and UID of the consumer, the nature of the call, the priority of the call, the estimated 
length of the call, and any other parameters the provider has specified in the scheduling method 
141. The scheduling method 141 then transmits this message object 1 10 to the provider's 
conununications object 1 10 at the provider program 12 (step 5003). When received by the 
provider program 12, the message object 110 executes a corresponding scheduling method 141 

30 (step 5004). This scheduling method 141 queries the provider's schedule objects 110 to 

determine the provider's current status (step 5005). The scheduling method 14 1 first tests the 
rcsuh set to see if the provider is currentiy available to take the phone calls (step 5006). If not. 
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the scheduling method 141 next checks the pro.videi's schedulins rules 140 and/or scheduling 
preference elements 147 to detennine if the provider wishes to schedule the phone call using 
automatic scheduling (step 5007). If so, th? scheduling method 14 1 proceeds with 
autdsphttjulujg as desci:ihed hclpw staiting « step.5Q70 of FIG>,46. If the provider doesojot wish 
5 tQ use, w|psph<!dul«g, tbssfsheduling method. 141 checks the. provider's scheduling-preferences 
. to determine, ifthe provider wishes to have a record ofthc phone call request (stqj 5008). If so, 
the scheduling method 141 executes the notification naethod 141 the provider . has assigned to 
unfiUmied phone call request messages (step 5009). In either case* the scheduling method 141 
proceeds to stq) 501$ bdow. 

10 Ift'ie test in step 5006 detennined the provider was available to take the call, the 

scheduling method 141 next checks the provider's scheduling preferences to see if the provider 

'w^ra to confirm phone cail requests (step 5010). Ifso, the schedule object 1 10 caUs the 
provider's notification method 141 for confirming phone caU requests (step 501 1.). NoUfication 
cgntrol gives a provider rich control over such requests. Notification processing can take into 
15 account all ofthe data included in the call request message object 110 plus all of the date 
in the combined programs 12, 22. This includes the consumer's identity, the presence or abse^ 
ofthe consumer UUD in the provider database 21, the priority ofa call, its expected length, an^ - ^ 

so on. By processing this data, a notification method 141 can produce any type of notification the « 
provider desires. For puiposes of this example, we will assume that this notification method - ^ 

20 generates an input form to obtain the provider's response. This forai displays tiie data expla^^^ 
above. An option to initiate a phone call immediately from the provider, back to tiie consumer 
could also be presented as a hyperlink or hypergraphic on this input form. The provider responds 
by submitting this input form (step 5012). This executes the scheduling mediod 141 which tests 
*he input form data to see iftiie provider wishes to taketiie call immediately (step 5013). If not, 
25,^ theschedulingmctiiodl41teststheinputfonndatatodetermineifti>eproviderhaschoosenan 
alternate time, for example scheduling the call to take place 10 minutes from now (siep 5014). If 
not, the scheduling method 141 determines if the provider wishes to schedule Uie phone call 
^ using automatic scheduling (step 5015). Ifso, the scheduling method 141 proceedswitii 

autoschedulingasdescribedbelowstartingatstep5070ofnG.46.Iftheproviderhaschosento ' 
30^, take the call, either immediately or at a later time, tiie scheduling method 14 1 next creates a 
schedule object 1 10 representing tiie scheduled phone call (step 5016). The scheduling metiiod 
141 saves this schedule object 1 10 in tiie provider database 1 1 (step 501 7). tiien creates a 
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message object 1 10 containing tBs schefliiile object 110 (step 5018). If the phoiie call request was 
denied for any reason, this message object 1 10 will contain a negative acknowledgment message. 
Lastly the scheduling method 141 transmits this message object 1 1 0 to the provider*s 
conmjuriicatiohs object 1 1 0 at the consumer program 22 (step 5019). When received by the 

5 consumer prbgram 22;the message object 110 executes a corresponding scheduling method 141 
(step 5020). This scheduling method 1 4 1 first tests the message object 1 1 0 to see if it contains a 
schedule object 110, nieahing the phone call request was accqited (step 5021). If so, the 
scheduling method 141 saves this schedule object 110 iii the consumer database 21 (step! 5022). 
The scheduling method 141 then tests the schedule object 1 10 to determine if the phone call 

10 should being immediately (step 5023). If so, the scheduling method 141 tests the constmier's 
sdieduling preferences to see if the phone call^ould be aiitodialed by the consumer pibgram 22 
(step 5024). If soi the scheduling method 141 executes' a transmission method 141 to autodial the 
provider's telephone number included in the schedule object 1 1 0 (step 5025). The phone call can 
take place via a public telephone hetwdric, via a private phone network, via the Internet, or via 

15 any other phone transmission network, as discussed in the transmission control section. Finally, 
the scheduling method 141 executestthe consumer^s:ndtification'method:141 for initiating phone 
calls (step 5026). If the phone call was not accepted in step 5021, or the phone call is not to begin 
immediately in:step.5023, or the phone call is not to-be autodialed in:step . 5024, then.a message 
to this effect-would be given to the consumerin step 5026: 

20 When either the provider or the consumer are not ready to proceed with a phone call 

immediately, schedule objects 1 1 0 can automate the process of scheduling a future pHone call. 
The steps in this process are illustrated in FIG. 46. This process can be used as an adjimct to the 
phone call request process described in FIG. 45, or it can be used without a prior call request. 
The process begins with the consumer executing a hyperlink or hypergraphic representing a 

25 voice call scheduling method 141 on a page within the provider's communications object 1 10 
(step 5051 ). The scheduling method 141 first queries the consumer database 21 to deteraiine the 
consumer's own schedule (step 5052). Then the scheduling method 141 tests consumer's 
prefefeiices for voice call scheduling to determine if automatic scheduling should be used (step 
5053). If not, the scheduling method 141 generates an input form (step 5054). This input form 

30 would present the consumer's current schedule, represented by schedule objects 1.1 Oi and allow 
the consumer to choose a time to schedule the phone call The consumer responds by submitting 
the input form (step 5055). Alternatively, if the consumer choose autoscheduling in step 5053, 
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the scheduUng method 141. uses the consumer's scheduling rules 141 and scheduling preferences 
1 47 tp^ ^etenmine: an optimal schedide time or timjes for the phone call (step 5056). In either case, 
once one or more proposed schedule times lia\;e been defcrrained, the scheduling methodi 141 
saye.s.,t^ conigs^wp^^ objept^UO. irt th^.^^ 21 <SEtep 5057).,Tliesc 

5 scbertiyfl?^ object^.! Ifi may have a "proposed"^attribute to indicate .Aeir unoonfinned status. The 
scheduling mptho4 141 now creates a message object 110 contaiaii^ th^ proposed schedule 
object or objects 1 10 (step 5058), The scheduling method 141 trmsmits this to the provider's 
communicatipns. object 1 10 at the provider prograni 12 (step 5059), When received by the 
provider program 12, the message object 1 10 executes a corresponding scheduling method 1 4 1 
^ 10 (step 5060), This scheduling method 141 queries the provider's schedule objects 1 1 0 to 

determine the provider's schedule (step 506 1 ), The scheduling method 1 4 1 first tests the result 
set to see if there are any matching schedule time slots between the consumer's proposed 
schedule objects 1 1 0 and the provider's schedule objects 1 1 0 (step 5062). If so, the scheduling 
method 141 next tests the provider's scheduling preferences to deiemiine if the provider wishes 
15 to manually confirm the optimal time match (step 5063). If not, the scheduling method 1 4 1 tests 
to determine if the provider desires notification of the new scheduled item (step 5064). If so, the 
scheduling method 141 executes the notification method 141 the provider has assigned to new 
schedule items (step 5065). This notification action may vary with the UID of the consumer, the 
type of events the duration of the event, and/or other scheduling or notification rules 1 40 or 
20 prefearences 1 47 established by the provider. If thae were no schedule niatches in step 5062, the 
scheduling method 141 checks the provider's scheduling preferences to determine if the provider 
wishes to proceed with automatic scheduling (step 5066). If not, the scheduling method 141 
executes the provider's designated notification method 141 for unfiilfilled call scheduUng 
requeists (step 5067). For purposes of this example, we will assume this notification method 141 
25 generates an input form (step 5068). This input form can present the proposed schedule times, 
the provider's conflicts, proposed alternatives, and so on. The provider responds by selecting one 
or moTp proposed schedide times and submitting tiiis input form (step 5069). If the automatic 
scheduling alternative was chosen in step 5066, the scheduling mctiiod 141 uses Uie provider's 
scheduling rules 141 and/or scheduling preferences 147 to determine an optimal time or times for 
3p the phone call (step 5070). Once tiie schedule time or times are determined in step 5062, 5069, or 
5070, the scheduling metiiod 141 saves the corresponding schedule objects 1 1 0 in the provider 
database 1 1 (step 507 1 ). These object's status attribute can indicate whetiier the schedule time is 
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proposed or confirmed: The sdiedulihg^etbod 14] then oreaiesa nfiessage object 110 containing 
the schedule Object or dbjects 110 (step 5072). Tlie sctediilmg meUiod 141 tran^nuts this 
message object 1 10 to the provider's commimicsSdhs object '! 10 at the cdhsmner program 22 
(step 5073). When received by^ttie coiisumef program 22, the message objfect 110 ekecutes a 
5 conesi^hdihg schwiu^ 141 (step 5074). This scheduling method 141 first qiienes the 

consumer's schedule objects 1 10 to detefltuhe the consumer's ciin-erit staitiis (step 5075). Iliis step 
is necessary as the coii^imef s status niay have changed since the last transmission. The 
scheduling method 141 then tests the result set to see if there are any matching schedule time 
slots between the proVidei^s schedule objects 1 10 and the consumers sch^dide objects 1 10 (step 
10 5076). If so» the scheduling method 141 rioct tests the consumer's schedulirig preferencefs to 
deterintne if the provider wishes to maiiually cbnfinri the optiiiial time match (step 5077). If not, 
the scheduling method 141 tests to detranine if the consumer desires notification of the new 
scheduled item (step 5078). If so, the scheduling method 141 executes the notification method 
141 the consumer has assigned to new schedule items (step 5079). If there were no si^hedule 
15 matches in step 5076, the scheduling method 1 4 1 checks the consumer's scheduling preferences 
to deterniiherif the consiimer wishes to continue with aromatic scheduling. (step SOSO)- . The 
consumer inay wish to limit autoschedulixig to a specified number of attem^^^ 
scheduling-method 141 executes the cpnsumerfs designated notification method 141 for 
unfiilfiUed call autoscheduiing requests (step 5081): For purposes of this . example, we v^dll 
20 assume this notification method 141 generates an input form (step 5082). This input form can 
preset the proposed schedule times, the consumer's conflicts, proposed alternatives, and so on. 
The consumer responds by selecting one or more proposed schedule times and submitting this 
input form (step 5083). If the autoscheduiing alternative was chosen in step 5080, the scheduling 
method 141 uses the consumer's scheduling rules 1 41 and scheduling preferences 147 to 
25 determme an optimal schedule lime or limes for the phone call (step 5084). Once the schedule 
time or times are determined in step 5076, 5083, or 5084, the scheduling method 141 saves the 
corresponding schedule objects 1 10 in the consumer database 1 1 (step 5085). The scheduling 
method 141 next tests td determine if the scheduling process is complete (step 5086). If not, the 
process is repeated starting with step 5058 (step 5088). 
30 Once a phone call has been scheduled, both the provider and consumer have copies of the 

same schedule object 1 10 in their respective databases 11,21. Should eiflier need to reschedule 
the phone call appoinunent, they need only edit the schedule object 1 10. Any changes will be 
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: amo;ip(i.cajly transmitted to the other pa^ty^ Each^can assign his/her ovm notification methods 
141 tQ the ^sphedule . object 110 in order to receive notification of changes in. exactly the manner 
eac^ piief^er^.. Xl^^^ schedule object 1 IQ also provides a channel for coinmimications related to the 
sch|sd}i|if^ jphphf^ $^l<)For exam party could ad() a mesfs^ge element (21 1, FIG. 4) 
5 coj^taining an fB6||c|a fo;: tbj^ phonp.cdl/md tiict;^ receive it automatically. At the time 

of the pbon| .^l, fmy eleip.^nt$, 143 or other related coimnianicatioiis objects or object 
components could be reeled automatically by the respective schedule objects 1 10. Additionally, 
the respective schedule objects 1 10 can also using event tracking control and reporting control to 
log the phone call and prepare call reports. 

;10 This scheduling automation process can b^ enhanc?ed through the addition of API 

functions that allow the programs 12, 22 to monitor the communications status of the user. For 
example, using a telephony API call, the programs 1 2, 22 could detcmiine if the user was 
currently on the telephone or another communications device and therefore imavaiiable to 
directly accept an incoming call. Such API calls would also allow the programs 1 2, 22 to contact 

15 the user or forward communications requests via other means, such as pagers, cellular phones, 
and so on. Because schedule objects 1 10 can cany the elements 143, methods 141, and rules 140 
necessary to communicate with the scheduled user at any point in time, the programs 12, 22 and 
any supporting servers 13 10 can take the place of "universal number" telephone processing 
, systems as described above. Such services are finthef enhanced by the feet that call routing can 

20 place locally at Ae calling computer 1 , 2 instead of at a remote phone switch or phone server. 
This technique for using schedule objects 1 1 0 can be generalized to many forms of 
scheduling. This includes business meetings; professional appointments; teleconferences or 
videoconferences; television, cable, or video shows; public seminars; and so on. The specific 
type of scheduling use is not a limiting feature of the invention. 

25 Applications ProgramniinP Interface r APT^ 

Comniunicatipns objects 1 1 0 encapsulate communications data, metadata, and 
instructions in order to create an automated communications relationship between the provider 
and consumer.. Additionally, these sets of data, metadata, and instructions are automatically 
^ maintained by the conununications system of the present invention. Therefore, the databases 1 L 
30 21, and 1 30 1 of communications objects represent an attractive central repository for any 

communications data that must be maintained by the provider or consumer on their computers 1. 
2, or 1302. or on a local area network to which those computers are connected. To access the 
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dataii metadata; and methiDds6f the cboSmuhic^tid^^^ Objects 110 st6iris»d iifi thdse dataMses, an 
appUcations progranimiiig intef&ce (API) can be used. An API ilefmes tKe itiethods and method 
panuneters that are to request services from anodier application within a desktop, server, or 
networic operating ehvifbnmehtY In a preferred embodiment, an API for a coiiuriunicatibns object 
5 system would specify ttic object semces availablb from a cohuriiaiid^b'r^^ objdcf System ^ 
program 12, 22, or 1302 in a foimat compatible with other indiiiitry ^timdifds ifor distributed 
object system specifications. Examples of such standards include the DCE and CORBA 
specifications from the Open Software Foundation and the OLE and DCOM specifications from 
Microsoft Corporation. 

10 When the provider and consumeir progriains 1 2, 22 include ah API, other computer 

applications can be relieved of the burden of storing, indejictng, and maintaiiiihg conununicatiozis 
data. For instance, the consumer does hot need separate address books for a pefsoiial 
infonnatioh maxiager, a networic directory, ahd an e-maiil program. Ofther applications can also 
use the API to automate commimications operations using the methods 141 and rules 140 stored 

15 in.thedatabases l 1,21, and 1301. A specific example of API usage is the word processing'file 
transfer process explaihed in the encoding control sectionTandnlliistratedim:FIG.:21: 

Object-Oriented Graphical . User Interface 

As explained above, the programs 12, 22, .1302 in a conmiunications object system may 

20 also employ a user interface, native to the operating system on which the program is run. Many 
computer operating systems, such as Microsoft Windows from Microsoft Corporation, Apple 
Macintosh from Apple Computer Corporation, and UNIX Motif from the Open Software. 
Foimdation, provide for graphical user interfaces. The use of graphical user interfeices for 
computer programs is discussed generally in Alan Cooper, About Face (1994), which is 

25 incorporated herein by reference. A graphical user interface is advantageous to a conununications 
object system because it allows a user of the programs 12, 22, 1302 to easily and intuitively 
manipulate visual screen objects in order to create, edit, or delete the underlying communications 
objects and object associations in the databases 11, 21, 1301. When used in conjunction with a 
conununications object system, this represents a imiquely powerful new interface technique for 

30 initiating and controlling conununications. 

User interface structures for an object-oriented graphical user interface for the combined 
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i pix^giBins 12, 22 ai« illustrated in FIG. 47, The computer screen 5101 includes one or more 
toolbars 51 11 together with one or more operating windows 5121, 513 1, 5141 . The toolbar 5111 
uses tool icons Sl 12 to gr^Jiical|y represent fiequently Uifed commands or c<fittmg functions of 
P^gi^nu; 12, 22. Similar toolbars are, employed by^rnost popular graphical software 
5 programs, including Microsoft Word from' Microsoft Goiporation; Visio from Visio Corporation, 
and Eudora from Qualgpinm Corpgradon. Example of functions that can be conttolled by tool 
icons 5112 include deleting an objectX323, FIG, 9) , publishing an object (326, FIG. 9), viewing 
or editing the properties of an object (322, FIG. 9), and creating associations between selected 
objects (312. 322, FIG. 9). 

,10 The author palette window 5121 allows the user to visually select different graphical 

icons for the purpose of creating or editing different types of communications objects or 
communications object components. Examples shown include a personal communications icon 
5122, representing an individual user communications object 1 10; a group communications icon 
^123, representing a user group communications object J 10; a telephone number icon 5124, 
15 representing a telephone number element 143; a news topic icon 5125, representing a notification 
element (201, FIG. 4) ; an open discussion icon 5126, representing a composite topic object 
(1451, FIG.29B) with a distribution list component to which additional recipients 120 can be 
added; a closed discussion icon 5127, representing a composite topic object (1451, FIG.29B) to 
which additional recipients 120 cannot be added; a response icon 5 128, representing a 
20 component response thread object (1461, FIG. 29B) for adding a response in a discussion group; 
and a meeting icon 5 1 29, representing a schedule object 1 1 0 for setting up a meeting. 

The user palette window 5131 allows the user to choose different screen icons 
representing other communications object system users in the databases 1 1 , 2 1 , or 1 301 . A user 
palette allows the user to quickly and easily create recipient associations (121, FIG. 3) or 
25 relationship associations (111, FIG. 63) or to take actions on other user objects. Examples shown 
include three individual user icons Alice 5 1 32, Bob 5 1 33, and Trent 5 1 34; and three user group 
icons Marketing 5135, Sales 5 1 36, and Development 5137. 

The author palette 5121 and user palette 5131 are just examples of the types of object 
icon palettes that could be used. The user may also create his/her own custom palettes. The 
:30 specific type of palette used is not a limiting feattire of the invention. 

The workspace window 5141 represents a screen area into which author objects and 
consumer objects can be copied using a mouse or other pointing device in order to manage a 
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specific set of cdnmuhicatioi^ This technique^ ctfteri called ''drag-ahd-^dfop", is 

employed in most operating systems losing gra^^ usief interfaces, including those mentioned 
above. The technique is specifically employed in aoiftwaine ptogiaihs that cthpilby object-based 
visual editing for drawing or fomis creatidtu such as Visio from Visid Corporation and Visual 

5 Basic from Microsoft edipbraiion. In a bommuhicatibns object system user intdrface, drag-iand- 
drop opcratibns can be used for creafing, editing, associating, desJsbciating, or deleting 
communications objects aiid commimications object componeiits. For example, a user could 
create a new open discussion topic 110 by dragging the open discussion icon 5126 into a 
workspace window 5 141 . The dragging action would result in a dialog box prompting the user 

10 for the new properties of the discussion topic object (1451, FIG29B). The resulting icon 1 542 
would then be ready for use. The user coiild then add other communications object system users 
to this discussion, such as Mary 5146 and Trent 5147, by dragging by dragging their icons from 
the user palette 5131 and dropping them on top of the discussion group icon S 126. The odier 
examples shown in the workspace 5141 include a closed discussion 5143, two schedided 

15 meetmgs 5144 and 5145, and a user group 5148 that has been added to one of the discussions 
1542,1543. 

The user can maintain multiple workspace windows 5141 pertaining to each of the user's 
areas of communications interestsnEor example; a user could organize:workspaces by projects, 
by departments, by priority, and so on. Workspace windows 5141 can be represented in the 

20 databases 1 1, 21, 1301 by folders (115, FIG. 3) or another separate workspace object class. 

Workspace windows 5141 can also be represented by communications objects 1 10 in order that 
multiple users can easily share the same workspace. In this case changes to one user's workspace 
5141 would be reflected in the workspaces of all other users who were consumers of this 
workspace 5141 . This same technique can be applied to object palettes 5121 and user palettes 

25 5131. 
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Besides drag-and-drop, other fef^ive3 of object-oriented grsq)hical user interfaces can be 
advantageous to a conunimications object syste^^. Thi^rl^^'^^^^ ability to edit the properties 
of an object or initiate an action on that object by using a spi^ial button or a sjMscial clicking 
action with a pointing device. A second feature is the use of gr^hicai dialog boxes for 
5 streaihUmhg u^ input Gr^liical dialog l)oxes could be used to replace many of the input forms 
required by data exchange methods 1 41 as described herein. A third feature is graphical 
seie&tion^tibib t^SHhiquel These allow a pi6mtihg'd(^vice to be used: to select one or more 
sCrSsiii obj&Vslfdr action by a prbgram command. Multiple screen objects can be selected by 
using the pointing device to draw a visual box around them. All of these techniques are 
, 10 employed by Visio from Visio Corporation, Visiial Basic from Microsbft Corporation, and other 
object-oriented editing systems designed for graphical user interfaces. All of these techniques 
could be employed to improve an object-oriented graphical user interface for a communications 
object system. 

Having thus described one particular embodiment of the invention, various alterations, 
15 modifications, and improvements will readily occur to those skilled in the art. Such alterations, 
modifications, and improvements are intended to be part of this disclosure, and are intended to be 
within the spirit and scope of the invention* Accordingly, the foregoing description is by way of 
example only and is not intended as limiting. The invention is lunited only as defined in the 
following claims and the equivalents thereto. 
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1 . A coinp^iter-'baised cbmniunicatibri system compnsing: 

a ihemory stonhg iiifomiation including data, metadata, and instructions; 
a conimunications diannel coimected to the memory for transmitting and receiving . 
5 portions of said infoiihation; 

association means for creating association metadata rqnesentipg as^ciajipns bpfween 
said data, metadata, and instructions, in said memory to control transniission and receptipn of said 
portions of said information from and to said mismory in said conmiunications channel; and 

communications processing means for processing.sdd association metadata tp.tamsmit 
10 and receive said portions of said information on said communications channel. 

2. The computer-based communication system of claim 1 , wherein said metadata 
includes data types and wherein said association means creates association metadata to represent 
associations between said data types and at least portions of said data. 



15 



3. The computer-based communication system of claim 1 , Auther comprising means for 
generating. uiiiqueisystem* data uniquely . identifying^said infomiation/in said system: and .wherein 
said association means creates association.metadata representing.'associations between said. 
information and said unique system data. 



20 



4. The computer-based conununication system of claim 1 , further comprising 
version means for generating state data identifying state of said information when said 
information in said memory is changed; and 

wherein said association means creates association metadata representing associations 
25 between said information and said state data. 

5. The computer-based comrnunication system of claim 1, further comprising: 

a second memory connected to said commimication channel storing at least one of data, 
metadata, and instructions; and 
30 external association means for creating association metadata representing associations 

between said at least one of data, metadata, and instructions in said second memor>' and said 



BNSOOCID: <W0_ 97322S1A1 l.> 



infonnation in said memory to control transmission and reception of said portions of said 
information on said communications channel. 



6. The computer-based communication system of claim I, wherein said association 
5 means creates association metadata between said metadat2{ in said information representing 

groupings of metadata. 

7. The computer-based communication system of claim 1, wherein said association 
metadata includes associations between portions of said information representing organization of 

10 said portions of said information on at least one display mechanism; and 

wherein said conmiunications ]>rocessing means includes: 

display means connected to said memory for processing said association metadata to 
control display of said portions of information; and 

display transmission means for transmitting said association metadata on said 
15 conununication channel when said data is transmitted to control display of said of said data, at a 
receiving location. 

8. The computer-based conununication system of claim 1, wherein said association 
metadata includes user preference metadata representing associations between said information 

20 and user defined actions to occur in connection with associated information of predetermined 
values; and 

wherein said conummications processing means includes: 

preference control means for processing said user preference metadata to execute said 
user defined actions when said information has said predetermined values. 



25 



30 



9. The computer-based conununication system of claim 8, wherein said user 
preference data includes a user preference value, and wherein said preference control means 
processes said user preference metadata to execute said user defmed actions when said 
information has predetermined values which exceed said user preference value. 

1 0. The computer-based conununication system of claim 8, wherein said user 
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prefeirace daUiisdeteimined by sai^ 



11. The computer-based communication system of claim 1 , wherein said association 
metadata represents associations between said infofmatioh and events; and 

5 wheitin smd communicadbhs proc^iiig m 

event processing means connected to said memory for processing S2dd association 
metadata to process events. 

12. The computer-based conununication syston of claim 1, wherein said metadata 

10 includes access control data and wherein said association means creates association metadata to 
represent associations between said information and said access control data; and 
wherein said communications processing means includes: 
" access control means connected to said memory for processing said association metadata 
to control access to said infonnation in said memory. 

•15- 

1 3 . The computer-based communication sy s^tem of claim 1 , wherein association 
metadata represents associations: between said infomiation and a plurality of users . of said 
memory, the associations defining access to portions of said information by each of said plurality 
of tisers; and 

20 wherein said communications processing means includes: 

multiuser control means connected to said memory for determining a user of said 
memory and for processing said association metadata to control access by an identified user to 
said portions of said Information defined by said associiations. 

25 14. The computer-based communication system of claim 1 , wherein association 

metadata represents associations between said information and a plurality of users of said 
memory, the associations defining processes to control transmission and reception of portions of 
said information associated with each of the users; and 

wherein said communication processing means includes means for processing said 

30 association metadata to transmit and receive data associated with at least one of said users. 
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15. The computer-based coilmunication system of claim 14, whiB^ 
communication processing means includes means for receiving response information relating to 
at least one of said users from said communicatipQ channel an4 for processing S£ud association 
metadata to associate said response informatipn with said at least one of said users. 

5 ' 

1 6. The computer-ba^ed communication system of claim 1 5, wherein said association 
metadata represents associations between response information received on said communication 
ciiannei relating to a first one of said users and at least one second user, and 

wherein said communication processing means includes means for processing said 
10 association metadata to provide access by said at least one second user to said response 
information. 

1 7. The computer-based communication system of claim 1, wherein said 
communications processing means includes means for translating portions of said information 

15 transmitted orreceived on said communications channel according to a selected markup 
language based upon processing of said association metadata. 

1 8. The computer-based communication system of claim 1, wherein said association 
metadata represents associations for receiving infomiation from a second memory, and wherein 

20 said communications processing means processes said association metadata to receive a portion 
of said information from said second memory. 

1 9. The computer-based communication system of claim 1 7, wherein said association 
means includes means for receiving said association metadata on said communication channel. 

' 20. The computer-based communication isystem of claim 17, further comprising: 
a second memory connected to said communication channel storing second information 
including data, metadata, and instructions, and second association metadata; and 
wherein said commtuiications processing means includes: 

transfer means for receiving said second information and second association metadata on 
said communications channel and storing said second information and second association 



25 



30 
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metadata in said memory; 

update detenhimng means for pnidessing saiid second association metadata to determine 
wlien said second informatidn in said second memory has been updated; 

transfer control nieans for processing said association metadata to receive a portion of 
. 5 said second information from said second memory to said memory when said i^date determining 
means determines that said second information has beeii updated. 

21 . The comptiter-based conununication system of claim 1 9, wherein said update 
detennining means includes: 

10 means for storing a first state value of a last update of said second information in said 

second memory; 

comparison means for comparing a second state value of itiformation previously received 
by said meinory from said second memory with said first state value of said last update 
information. 

15 . 

22. The computer-based communication system of claim 19, wherein said second 
informationancludesacommunications network server address and.polling control data, and" 
wherein said second association metadata includes an association between said network server 
address, polling control data and said second information; and 

20 wherein said transfer control means includes: 

polling trigger means for processing said polling control data to trigger update 
processing, 

instruction retrieval means for retrieving transfer instmctions from said memory based 
Upon said polling control data, 

25 access means for accessing a server at said network server address to request transfer of 

said updated second information according to the transfer instructions retrieved fit)m said 
memoiy; and 

reception means for receiving said updated infomiation transferred by said server, in 
response to a request and for storing said updated information in said memorj'. 

30 

23 . The computer-based communications system of clmm 2 1 , wherein said polling 
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t|igger meaQS jt^gg^rs update processing at a variably determined time after aii update of the 
information based upon said association metadata. 

24. The computer-based communication system of claim 19v M^eitiin s£idse<ioi(d 

^ S information mcludes a communications network address associated with said memory, and 
Mlierein said metadata includes an association between said communications network address 
and said secoiid information; and 

wherein said transfer control means includes: 

transfer nieans for transferring said second information to said communications networic 
10 address, 

access means for accessing said communication networic address from said memory to 
retrieve said updated second information, and 

reception means for receiving said updated second information transferred froin said 
communications network address and for storing said updated second information in said 
15 niemory. 

25. The computer-based communication system of claim 1 8, wherein said second 
information includes a communications network casting address, and wherein said metadata 
includes an association between said casting address and said second information; and 

^ wherein said transfer control means includes: 

instruction retrieval means for retrieving transfer instructions associated with said 
information from said memory; 

monitoring means for monitoring said casting address from said consumer memory to 
retrieve said updated second information based upon said transfer instructions, and 
25 reception means for receiving said updated second information from said casting address 

and for storing said updated information in said memory. 

26. The computer-based communication system of claiin 19, wherein said metadata 
includes notification metadata of associations that can.be processed to control notifying a user 0 

30 at least portions of the updated second information; and wherein the system further comprises 
notification means including: 
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instnictidn feirieval means for retrievihg ridtificaribn imtructioiis associated with said 
updated second information in said memory; and 

instniction execution means for executing said notification insu-uctions to notify the user 
of said iti^iated second information. 

5 - - • • ■ . • 

27. The di)ihputCT-based conMii 19, wherein said metadata 

includes notification metadata of associations that can be processed to control notifying a 
mechanism of at least portions of the updated second information; and wherein the system 
further comprises notification means including: 
10 instniction retrieval means for retrieving notification instructions associated mth said 

updated second information in said memory; and 

instniction execution means for executing said notification instructions to notify the 
mechanism of said updated second infoimatioh. 

15 28. The computer-based commimication system of claim 25, wherein said notification . 

metadata, includes a plurality of information references, each information reference being 
associated with a portion of the updated second information; and 
wherein said instruction execution means includes: : 
user preference means for receiving at least one user reference^ 
20 preference comparison means for comparing said plurality of information references to 

said at least one user reference, and 

reference notification means for notifying the user of portions of the updated information 
associated with information references which correspond to said at least one user reference. 

25 29. The computer-based communication system of claim 1 7, further comprising: 

a second memory connected to ssud conununication channel storing second information 
including data, metadata, and instructions, and second association metadata; and 
wherein said communications processing means includes: 

transfer means for receiving said second information and second association metadata on 
30 said communications channel and storing said second information and second association 
metadata in said memory; and 
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. . fUsfJay means cpnnecu^. to.said memory for processing said second association meudata 
to control display of said second information. 



30. The computer-based communication system of claim 1 7, further comprising: 

5 a secon^ memory connected to said communication channel storing second information 

, including data, metadata, and instructions, and second association metadata; and 
wherein said communications processing means includes: 

transfer means for receiving said second information and second association metadata on 
said communications channel and storing said second information and second association 
10 metadata in said memory; and 

categorization means connected to said memory for processing said second association 
metadata to control categorization of said second information. 

> 

31. The computer-based communication system of claim I , wherein said association 
15 metadata represents associations for transferring information to a second memory, and wherein 

said communications processing means processes said association metadata to transmit a porUon 
of said information to said second memory. 

32. The computer-based communication system of claim 3 1 , wherein said association 
20 means includes means for receiving said association metadata on said, communication channel, 

33. The computer-based communication system of claim 32, wherein the association 
metadata includes response metadata for controlling a transfer of response information stored in 
the memory to a communications address specified by said response metadata: and 

25 the system further comprising: 

' transfer means, associated with the memory, for processing the response metadata to 
transfer said response information.to said communications address. 



30 



34. The computer-based communication system of claim 33, further comprising:. 

request means, associated with the memory, for requesting the response information 
from a user; and 
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input means for receiving th^ res[x>n5e infohhation ixiput by a user and storing said 
response information in the memory. 



35. The computer-based conimunication systeiti of claim 33, further comprising: 
5 query means fori^iplying aqueiy to'the informatidh iii said memory to obtain said 

response information. 

36. The computer-based communication system of cium 33, further comprising: 
external queiy nieans for transmitting a query request on said conununications channel to 

10 obtain query information to be stored in said memory. 

37. The computer-based communication system of claim 33, further comprising: 
change means for detemiining when response information in said memory has changed; 
instruction execution means for processing said response metadata to transfer said 

15 response informatioh which has changed from said memory to said communicationsvaddfess..;.: 

38. The computer-based conrniimicationsystem of claim 32, wherein the association 
metadata received from the communication channel includes transfer metadata for transferring a 
portion of the information stored in the memory to a second memory; and 

20 the system further comprising: 

transfer means, associated with the memory, for transferring ^d portion of said 
information in said memory to said second memory based upon said transfer metadata. 

3 9. The computer-based communication system of claim 3 1 , further comprising: 
25 a second memory connected to said communication chatuiel storing second information 

including data, metadata, and instructions, and second association metadata; and 

wherein said association means associates said second information with an address on 
said communications channel; and 

wherein said communications processing means includes: 
30 transfer means for receiving said second information and second association metadata on 
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said commijuucations ch^el and storing said second infonnation and second association 
metadata in said memory ; and 

forwarding means for processing said association metadata to transmit said second 
infoimatipi? to said aid(lress. 

5 

40. The computer-based communication system of claim 37, wherein 
said communications processing means fitrther includes: 

update determining means for processing said second association metadata to determine 
when said second information in said second memory has been updated; 
10 transfer control ipeans for processing said association metadata to receive a portion of 

said second information from said second memoiy to said memory when said update determining 
means determines that said second information has been updated; and 

wherein said forwarding means transmits said second information to said address when 
said second infonnation is updated. 

15 

4L The computer-based communications system of claim 32, wherein said association 
metadata includes an association with second information at an address on said communications 
chaimel; and ' *^ 

wherein said communications processing means includes linking means for processing 
20 said association metadata to receive said second information and store said second information in 
said memory. 

42. The computer-based communications system of claim 39, wherein said linking 
means retrieves said second information when predetermined information is received on said 
25 communications channel. 

.43. The computer-based communications system ofclaim 31, wherein said 
communications channel includes a plurality of communications networks; and 

wherein said communications processing means includes means for processing 
30 association metadata to select at least one of said plurality of communications networks for 
transferring said portion of said information to said second memory. 
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44; The computer-based c^mihuhicatiocis i^kem of claim 3 1 , \vherein SEud 
communications chamiei includes a plurality of communications networks; and 

wherein said communications processing means includes means for processing 
association metadata to select at least one of said plurality of channels for transferring said 
5 portion of said information to said second memory. 

45. The computer-based Gi6rhmuhicaii6i£5 system of claim 3 1 , wherein said 
communications chaxmel includes a plurality of channels; and 

wherein said communications processing m&ahs includes means for processing 
10 association metadata to select at least one of said plurality of chaimels for transferring said 
portion of said information to said second memory. 

46. The computer-based communications system ofclaim 31, wherein said 
communications channel includes a plurality of servers; and 

IS wherein said communications processing:ineans:includes:meansrfoF:processi^^ . ^. 

association metadata to select at least piie of said plurality of servers for transferring said portion 
of said information to said second memory: 

47. The computer-based communications system of claim 3 1 , wherein said 

20 communications processing means includes means for processing said association metadata to 
select at least one of a plurality protocols for transferring said portion of said information to said 
second memory. 

48. The computer-based communications system of claim 31, wherein said 

25 conununications processing means includes means for encoding said portion of said information 
according to at least one of a plurality of encoding processes based upon processing of said 
association metadata. 

49. The computer-based communications system of claim 48, wherein said encoding 

30 processes include at least one of compression, encryption, digital signatures, file formatting, and 
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data translation. 

50. The computer^ba^ed communications system of claim 48, wherein said encoding 
processes include asymmetric encoding in accordance with one.of a plurality of public keys and 

5 private keys, and wherein said second association metadata includes an association to a selected 
on of the plurality of public and private keys. 

51. The computer-based communications system of claiin 50, wherein said asynunetric 
encoding includes at least one of encryption and digital signing. 

10 

52. The computer-based communications system of claim SO, wherein said plurality of 
public keys and private keys includes a plurality of key pairs, each key pair including a public 
key and a private key, and 

wherein said communications processing means includes means for selecting one of the 
15 plurality of key pairs, and for transmitting a signal identifying said selected key pair. 

53. The computer-based conununications system of claim 5 1 , wherein said 
communications processing means includes means for receiviiig a signal identifying a selected 
key pair, and means for decoding said second information based upon said selected key pair. 

20 

54. The computer-based communication system of claim 1, further comprising: 
a second memory connected to said communication channel; 

wherein said association means associates a portion of said information with said second 
memory; 

25 wherein said communications processing means includes update transfer means for 

processing said association metadata to transfer said portion of information to said second 
memory through said communication channel when said portion of said information is updated. 

55. The computer-based conununication system of claim 54, wherein the portion of 
30 information includes response metadata which is processed to conU-ol a transfer of response 

infomiation stored in the second memory to a communications address, which is connected lo the 
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communications chaiineH and 

wherein the communications processing means further includes: 

reception mefans for receiving the i^sponse infdniiatidh fit}m the communications address 
and storing it in> the memory . 

56. The compiiter-based conununications systdn of claim 54, v^em 
association means includes means for modifying said portion of said information associated with 
said s^nd memory based upon said second response inforihaiton. 

10 57, The computer-based communications system of claim 54, wherein said 

association metaidata includes acknowledgment metadata ^ich is processed to control 
transmission and reception of acknowledgments; and 

wherein the commimicauons processing means fiolher includes acknowledgment meaiis 
for processing the acknowledgnaeiit metadata to receive and process an acknowledgment to 
15 transfer of said information. 

58. The computer-based .communications system of claim 57, wherein said 
acknowledgment metadata includes an association between a transfer of said information and a 
maximum time to receive an acknowledgment, and 

20 wherein said acknowledgment means retransmits said portion of said information if an 

acknowledgment is not received within the maximum time. 

59. The computer-based communications system of claim 58, wherein smd 
acknowledgment metadata includes an association between a transfer of said information and a 

25 retry limit; and 

wherein said acknowledgment means stops retransniitting said portion of said 
infonhation if an acknowledgment is not received before said retry limit is reached. 

60. The computer-based communication system of claim 59, wherein said 

30 acknowledgment metadata includes an asisociation between said retry limit and a retry failure 
action; and 
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wherein S2dd..ac]biowledg^ rneans includes means for executing said retry failure 
action when said retry limit is reached,: 

61. The computer-bapecj qqifp^unic^tion system of clai 1, wherein the information 

5 includes event data repre3enting fiiture communicadon event$ anticipated at respective times, and 
wherein the association i|ieta4a^; ^sopi^tes ^h eypn:t in said event dfita. with at least pne 
respective conimuniqationpripc^ss; and 

wherein sai^ communications prpceissing means includes event means for executing at . 
least one respective communication (mocess at times coiresponding to a future communication 
10 event 

62. The computer-based conunimication system of claim 1, wherein the information 
includes event data representing communication events, and wherein tiie association metadata 
associates each event in said event data with at least one recoiding process; and 

15 wherein said communications processing means includes event means for executing said at 
least one recording process v4ien an associated commtinication event occurs. 

63. The computer-based communication system of claim 61, wherein said event 
means executes at least a second respective communication process if a future communication 

20 event does not occur an one of said times. 

64. The computer-based conmiunication system of claim 61, wherein said at least one 
respective communication process includes storing data representing occurrence of a future 
commimication event 

25 *: 

65. The computer-based communication system of claim I, whereiti said information 
also includes rules, and said association means creates association metadata represehting 
associations between said rules and said data, metadata and instructions of said information such 
that.a rule is processed when a communication event occurs with respect to associated 

30 information; . 
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conununicalion pfocessihg i^^ rule piodessing iiieans for processing at 

least one rule when associated information is receivei 

66. ThexoinpUter-based rorhmiiuditidn sy^eni of clauxi^65, A^erein s^d at least one 
5 of said riiles is a riilelxihtiol rule definiiig 'jg£ proc^'foir disiermuung another rule to be processed 
u^en ihfomiatibii » 

wherein said rule processing means processes said rule cbhtrol riile based upon received 
information to detertxiine a secorid rule to be processed arid processes the second rule. 

10 67. The computer-based communication system of claim 1 7, wherein said information 

includes an authentication rule associated with a portion of the information defining a process for 
determining the source ofiiiformation lecei vied on the coiximuhi and 
wherein said communication processing meaiis includes means for processing the 
authenticatioil rule to autheilticate a soinxe of received tnfprm^^ 
15 " 

68. The computer-based communication system of claim 25, wherein said . 
iiifornimion incliides a notification rule defining a proces 

metadata to be processed to notify a mechanism of at least portions of the updated data based 
upon types of the portions of updated daita; and 
20 wherein said communication processing means includes means for processing the 
notification rule to determine specific notification metadata to be processed; 

. 69. The computer-'based communication system of claim 1 , >^erein said association 
means is associated vnlh a second memory and a portion of said association metadata is 
25 transferred to said first memory through said communication channel; 

i^erein said association metadata includes first association metadata representing 
associations for commuiucating information to and from said second memory and second 
association metadata representing an association with a third memory; 

wherein said communications processing means processes si^d association metadiata to 
30 retrei ve a portion of second information fi-om said third memory; 
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wher^in ppition of said second information includes third association metadata 
i^i^enting asspciations.fbr comrnumcatiiig infoixnation to and from said third memory; and 

wherein said communications processing means processes said association metadata to 
transmit and receive said portion of said information on said communication channel to and from 
5 said second memory or said third memory, 

70. The cpniputer-basfid communication system of claim 69, wherein said second 
memory includes, name data representing information in said third memoiy; 

wherein said conununications processing means processes said association iiietadata to 
10 transfer said name data between said first memory, second memory, and third memory; and 
wherein said association means means processes said association metadata to create . . 
association metadata representing a name association between said first memory, second 
memory, and third memory. 

15 71. The computer-based communication systehi of claim 69, wherein said second 

memory includes category metadata representing information in said third memory; 

wherein said conununications processing means processes said association metadata to 
transfer said categoiy metadata between said first memory, second memory, and third memor>'; 
and 

20 wherein said association means means processes said association rnetadata to create 
association metadata representing a category association between said first memory, second 
memory, and third memory. 

72. The computer-based communication system of claim 69, wherein said second 
25 memory includes encoding information; 

wherein said communications processing means processes said association rnetadata to 
traiisfer said encoding information between said first memory, second memory, and third 
memory; and 

wherein said association means means processes said association metadata to create 
30 association metadata representing an association between said encoding information and said 
first memory, second memory, and third memory; and 
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wheiein said coiimnix&atidns pidcessmg oTdms |)iocissses said assdeiation metadata to 
encode and decode infomiatibn traiiSfeifed betweien sud fibt irieiiiory , second memory, and third 
memoiy. 

5 73, The computer-based communication system of cl^m 69, wherein said second 

memory includes authentication information; 

wherein said communications processmg means proicesses said association metadata to 
transfer said authentication information between said first memory, second memory, and third 
memory; and 

10 wherein said association nieans means processes ^d association metadata to create 

association metadata representing an association between said authentication information and 
said first memory, second memory, and third memory; and " 

wherein said communications processing means processes said association metadata to 
authenticate the identity of the originator of information transferred between said first memory, 

15 second memory, and third memory. 

74. The computerrbased. communication system of claim>69, wherein said second 
memory includes payment . information;'^ . 

wherein said communications processing means processes said association metadata to 
20 transfer smd payment information between said first memory, second memory, arid third 
memoiy; and 

wherein said association means means processes said association metadata to create 
association metadata representing an association between said payment information and said first 
memory, second memory , and third memory; and . 
25 wherein said communications processing means processes said association ihetadata to maice 
or receive payments between said first memory, second memory, and third memory, 

75. The computer-based communication system of claim 69, wherein said second 
memory includes reporting information; > 

30 wherein said commimications processing means processes said association metadata to 
transfer said reporting information between said first memory, second meraor^% and third 
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memory; gnd., 

wheijBin said asisociation m^s means processes said association metadata to create 
association iqfi.etadsu(a repres^ntipg an association between said reporting information and said 
first me|n.Qiy^ second memory, and third rae9K>i7; 
5 wherein said communications processing means processes said association metadata to send 
or receive statistips on communication^ events generated by infpimadon transferred between said 
first memory and third memory. 

^. 

16, The computer-based communication system of claim U wherein said association 
10 mea^s is assppiated with a second memory and a portion of said association metadata is 
transferred to said first memory through said communication channel; 

wherein said association metadata includes first association metadata representing 
associations for communicating information to and from said first memory and second 
association metadata representing associations for communicating infomiation to and from said 
15 second memory; 

u^erein said association means creates third association metadata representing ah association 
between said first association metadata and said second association metadata; 

wherein a portion of said information including a portion of said first association metadata 
and a portion of said third association metadata is transferred to a third memory; and 
20 wherein said. communications processing means processes said association metadata to 
transmit and receive said portion of said information on said communication channel to or from 
said second memory or said third memory. 

77. The computer-based communication system of claim 76, wherein said second 
25 memory includes name data representing information in said first memory; 

wherein said communications processing means processes said association metadata to 
transfer said name data between said first memory, second memory, and third memory; and 
wherein said association means meanis processes said association metadata to create 
- association metadata representing a name association between said first memory, second 
30 memory, and third memory. 
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78. The computer-based communication system of claim 76, wherein said second 
memory includes category metadata representing infonniation iii said first memory; 

wherein said communications processing means pibcesises said assodiation metadata to 
transfer said category metadata between said first memory; second meniory, arid third memory; 

5 and . ; . 

wherein said association means means processes said associatioh metadata to create 
association metadata representing a category association betwieen said firist naernory, second 
memory, and third memory. 

10 79. The computer-based commimication sys^ of claim 76, \^e^ 

memory includes encx>ding information; 

wherein said communications processing ineans processes said associiation metadata to 
transfer said encoding information between said first memory, second niemory, and third 
memory; and 

15 wherein said association means means processes said association metadata to creates 

as$ociation;metadata:representingmassociation'between:said^enc^ 

first memory, second memory^ and third memory; and /. 

wherein said.cotmnunications^processii^ means -processes said association metadata to • 

encode and decode information transferred between said first memory, second memory, and third 
20 memory.. . 

80. The computer-based communication system of claim 76, wherein said second 
memory includes authentication information; 

wherein said communications processing means processes said association metadata to 
25 transfer said authentication information between said first memory, second memory, and third 
memory; and 

wherein said association means means processes ssud association metadata to create - 
association metadata representing an association between said authenticadon information and 
said first memory, second memory, and third menaory; arid 
30 wherein said communications processing means processes said association metadata to 
autheiiticate the identity of the orig'mator of iriformation u^sferred between said first memor)% 
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second memory, and third memoiy . 

8 1 . The computer-based communication system of claim 76, wherein said sdbond 
mempiy includes payment informauon; 

5 wherein said conmiunications processing means processes said association metadata to 
transfer said payment informatioii between said first memory, second ihenlory, aiid third, 
memory; and. 

wherein said association means means processes said association metadata to create 
association metadata representing an association between said payment inforination and said first 
10 memory, second memory, and third memory; and 

>^erein said conununications processing means processes said association metadata to make 
or receive payments between said first memory, second memory, and third nnemory. 

82. The computer-based communication system of claim 76, wherein said second 
15 memory includes reporting information; 

wherein said communications processing means processes said association metadata to 
transfer said reporting information between said first memory, second memory, and third 
memory; and 

wherein said association means means processes said association metadata to create 
20 association metadata representing an association between said reporting information and said 
first memory, second memory, and third memory; and 

wherein said communications processing means processes said association metadata to send 
or receive statistics on communications events generated by information transferred between said 
first memory and third memory. 

83. A computer-based conununication system comprising: 
a provider memory storing mformation including data, metadata, and instructions; 
a consumer memory; 

transfer means for transferring said information from said provider memory to said 
30 consumer mernory; 

association means for creating association metadata which caii be processed to determine 
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an update of said information and to control conimunic&tibn of smd ifi^^ v^m it is 

updated, said association metadata including associations between said data, metadata, and 
instructions; 

update determining means for processing said information t6 determine when said 
.5 information in said pn>vider memoiy ^ . ' . 

transfer control means for piocessing said infotroation to transfer a portibn of said 
information from said provider memory to said consumer memoiy when said update determining 
means determines that said information has been updated. 

10 84. Thecompute^basedcon^municatidnsyste^^■6ifclaim83^ 
determining means includes: 

versioning means for storing a first version value of a last update of said infoimation in 
said provider memory ; 

comparison means for comparing a second version value of information previously 
15 transferred to said consumer memory with said first version value of said last update information: 

85. The compiiter^based communication system of claiin 83, wheiein said 
information includes a communications network server address and polling control data,.ahd 
wherein said metadata includes an association between said network server address, polling 
20 control data^ and a portion of said information to be transferred to said server when said 
information is updated; and 

wherein said transfer control means includes: 

(a) transfer means for transferring said portion of said information from said provider 
memory to a server at said network server address as updated information, 
25 (b) polling trigger means for processing said polling control data to trigger update 

processing at the consumer memory, 

(c) instruction retrieval means for retrieviiig said transfer instmctions from said 
consumer memory based uj)on said polling control data, 

. (d). . access means for accessing said server at said networic server address to request 
30 transfer of said updated information according to the transfer instmctions retrieved from said 
consumer memory, and 
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(e) reception me^ for receiving updated information transferred by said server 
in response to a request an<i for storing said updjOed inforniation in said, consumer memory. 

86. Tlie. computer-based .conu^ system of claim 83, wherein said 

5 information includes a cpnmiiUniQation^ netwoi^ addiie^s associated with said eonsumermemory, 
and wherein said metadata includes an association between said communications network 
. v^. address and a portion of said information to be transferred to said consumer mentory when said 
information is updated; and 

wherein said transfer control means includes: 
10 (a) ins^ctipn retrieval means for retrieving transfer instructions associated with said 

infoimation from said provider memory, 

(b) transfer means for transferring said portion of information to said communications 
network address according to the transfer instructions retrieved from said provider memory as 
updated infonnation^ 

. 15 (c) access means for accessing said communication network address from said 

consumer memory to retrieve said updated information, and 

(d) reception means for receiving said updated information transferred from said 
communications network address and for storing said updated information in said consumer 
memory. 

87. . The computer-based communication system of claim 83, wherein said 
infomiauon includes a communications network castii^ address, and wherein said metadata 
includes an association between said casting address and a portion of said infomiauon to be 
trahsfeited to said consumer memory when said information is updated; and 

25 wherein said transfer control means includes: 

(a) provider instruction retrieval means for retrieving said transfer instructions 
associated with said information from said provider memory, 

(b) transfer means for transferring said portion of said information to said casting 
address according to die transfer instructions retrieved from said provider memory as updated 

30 information, 

(c) consmner instruction retrieval means for retrieving said u-ansfer instructions 
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associated with said ilifdnnatidn fro^ said 6c«i^imer ih^^ 

(d) monitoring meaais for moiStonng said casting address from said cpnsimier 
memory to retrieve said updated information based upon said transfer instructions, and 

(e) reception means for receiving said lipdated iiifoirtiation from said casting address 
5 and for storing said updated iiiforaiatioh in said consunCT ihemory 

88. Tlic cdihputer-based cdiximunication system of claim 83, wherein said metadata 
includes notification metadata, said notification metadata including associations that can be 
processed to control notifying a user of ai ieasX pdr^oiis' of thiei updated infoiniation; and 

10 wherein the ^stem fiiither comprises notification means including: 

(a) instruction retrieval means for retrieving notification instructions associated with 
said portions of said updated inforination in said consumer memory; 

(b) instruction execution means for executing smd notification instructions to notify 
tiie user of said updated information. 

15 

89. The computer-based communication system of claim 88, >^erein S£ud notification 
metadataiincludesa.plurdity of information references^each:infomrlation.r^^ 

associated with a portion of the iq)dated information; and 
wherein said instruction execution means includes: 
20 (a) user preference means for receiving at least one user reference, 

(b) preference comparison means for comparing said plurality of information 
references to said at least one user.reference, and 

(c) reference notification means for notifying the user of portions of the updated 
information associated with information references which correspond to said at least one user 

25 reference. 

90. The computer-based conununication system of claim 83, wherein the information 
includes provider response information for controlling a transfer of consumer response 
information stored in the consumer memory to a communications address specified by said 

30 provider response information; and 

the system further comprising: 
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coQSumertr^^ 

provider response information to transfer said consumer response information to the 
communications address. 

5 J^P cpnjputer-ba^ poppiumc^atipn^^ 90, wherein the 

conununications addrcss is asso^ prpyidermismory, and 

the system fiirther comprising: 

reception means^ ^sociated with thi^.prpvider memory, for receiving the consumer 
response information from the communications address and storing it in the provider cnemor>'. 

10 

92. The computer-based communication system of claim 90, further comprising: 
consumer request means, associated with the consumer ihemory, for requesting the 

consumer response information &om a user; and 

consumer input means for receiving the consumer response information input by a user 
15 and storing said information in the consumer memory. 

93. The computer-based communication system of claim 90, further cdmprisihg: 
update determining means for determining when consumer response information in said 

consumer memory has been updated; 

20 instmction execution means for processing said provider response information to transfer 

said consumer response information which has been updated from said consumer memory to said 
communications address. 

1 1: 94. The computer-based communication system of claim 86, wherein thie information 

25 includes provider response instructions for transferring consumer respdnse information stored in 
the consumer memory to the provider menrioiy ; and 
.the system further comprising: 

consumer transfer means, associated with the consumer memory, for transferring said 
consumer response information to the provider memory based upon the response instructions: 
30 and 

wherein said association means associates portions of said information in said provider 
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95. A computer-based method for communicating updated information comprising 
the steps of: 

5 associating uifoi^ ttiiiyita^ aihd iiii^ctions in a provider memory, 

said metadata including fiussociMibiis Wbe pbce^sbd tS^ ^aiiSg tianSGa^ of a portion of said 
information to a consumer memory; and 

transferring the portion of said informafion from the provider inemoiy to the consumer 
memoiy; 

10 determining ^dien the portion of said information in said provider memory iias been 

updated; 

processing said information to transfer said portion of said information fix)m said 
provider memory to said consumer memory when the pohion of infohnation in said provider 
memory has been determined to have been updated 

15 

96. The computer-ba^ method of claim.95, wherein said information includes 
nodficiUioninfornrntion representing a.processfor.notifying.a.user^^^^^ of the 
i^Klated information; and 

the method further comprising the step of processing said notification information to 
20 notify the user of said at least portions of the updated informationu 

97. The computer-based method of claim 96, further comprising the steps of: 

setting user preferences representing types of information for which a user is to be 
notified of updated information; 

25 comparing iqxiated information with said user prefer^ces; and 

^ notifying the user of updated infoimaidoh based upon the comparing step. 

98. The computer-based communication system method of claim 95, wherein the 
information further includes provider response information including a communications network 

30 address for transferring consumer response information; and the method further comprises the 
steps of: 



'BNSOOCID: <WO. g732251A1 I > 



-219- 

^ .^.^ pip^cjessi^g saifi,^pQvi4qr riespOiits^ jnfonnfUiQnito transfer said consumer response 
infonnation froxn s^d c^nsum^ memory to said conunjunications networic address. 



. 99. jniexomputerTj^iisc^ oommunication system method of claim 98, wherein the 
^ 5 communications address is associated with the provider memoiy ; and the method further 
comprises the stqjs of: 

proces^iiig said provider response information to transfer said consumer response 
information from said consumer memory to said provider memory; and 

receiving and storing the consumer response infonnation in the provider memory. 

10 

1 00. The computer-based communication system method of claim 98, wherein said 
processing step includes: 

requesting consumer response information from a user; and 

receiving consumer response information input by a user, 

15 Storing said consumer response information in the consumer memoiy; and 

transferring said consumer response infonnation to said communications address. 

101. A computer-based communication system comprising: 

a provider memory storing provider infonnation including data, metadata, and 
20 instructions; the information including provider response information for controlling 
communications with the provider memory; 

a consumer memory storing consumer information; 

transfer means for transferring said provider information from said provider memoiy to 
said consumer memory; and 

25 response means, associated with the consumer memory, for processing said provider 

respdnse infonnation to transfer said consumer infonnation to said provider memory* 

-^i- '02. The computer-based communication system of claim 10 1 , wherein said consxmier 

infonnation includes consumer response infonnation for controlling communications with said 
30 consumer memory; said system further comprising: 
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secbhd'transfer m^ans for'tia^^ said co'h^umCT re^i^ iiifomijiiidn fibm said 
consumer mraidrjr to ssud provide mimolry based upfen said provider response information: and 

. second response means, associated with the provider memory, for processing said 
consumer response information to transfer provider iMonnatidii to said consumer memory. 

5 

103. The computer-based communication system of claim 101, furiher coiiipnsing: 
detenhihing xiieans for determining vAei cdnsumier informatibn has changed in the 

consumer memory; 

update means for trahsferring consumer infdnhatioh v^ch has b^en updated to said 
10 provider memory based upon said provider response informatiorL 

104. The computer-based communication system of claim 102, further comprising: 
determining means for determining ^en prb^dder information has changed in the 

provider memory; 

15 update means for transferring- provideriinformation which has been updated to said 

coiisumer memory based upon said consumer respoiise mforiiiatioit 

105. The computer-based comniunication system of claim 102, further comprising 
selection means for selecting a portion of information stored in said provider memory to be 

20 transferred to said consumer memory. 

1 06. The computer-based communication system of clainn 1 05, wherein said portion is 
selected based upon said consumer information transferred to said provider memory. 

25 107. A computer-based method for communicating information on a communication 

channel, conlprising the steps of: 

creating association metadata representing associations between information iiK:luding 

data, metadata, and instructions, and defihing.processes for traiisferring information on said 

corhmunication chaimel; and 
30 processing said association metadata to trahsnut and receive information on said 
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108. The computer-based method according to claim 1 07v further comprising the steps 
of:' . / . . 

. 5 receiving information from a source connected to said conmiunication channel; 
determining when information from said source has been updated; and 
processing said assbciaUon metadata to rdceive informatidh from said source which has 
been updated. 

10 1 09. The computer-based method according to claim 1 07, wherein said association 

metadata is created by receiving said association metadata from a soiuce connected to said 
communication channel, the method further comprising the steps of: processing stud association 
metadata to transfer data to said source. 

15 110. The computer-based method according to claim 1 07, wherein said association 

metadata represents associations between portions of said information and a communication 
entity connected to said communication channel; the method further comprising the step of 
processing said association metadata to transmit said portions of said information to said 
communication entity. 

20 

111. The computer-based method according to claim 1 1 0, wherein said creation step 
. . includes the step of receiving said association metadata transmitted on said communication 
channel. 

25 ,112. The computier-based method according to claim 1 07, wherein said association 

metadata includes associations between said data representirig organization of said data on at 
least one display mechanism; and 

wherein said method further comprises the steps of: .... 

organizing said data based upon said associatibn metadata to determine organization of 
30 data in connection with the at least one display screen; and 
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displaying said at least one display screen. 

1 1 3. Tlie Gomputer-baised method according to claim 1 12, wherein said creation step 
includes the step of receiving said association metadata transmitted on said communication 
5 channel. 



114. The computer-based method according to claim 1 07, wherein said association 
metadata represents associations between a portion of the information, a transmission process 
and a destination connected to said communication channel; 
10 the method further comprising the step of: 

executing said transmission process to. transmit an associated portion of the information 
to said destination. 

lis. The computer-based method according to claim 1 1 4» v4ierein said executing step 
IS includes.encoding'said associated portion of the information according to a selected encoding 
process based upon said association metadata. 



116. The computer-based method according to calini ,114, wherein said executing step 
includes encrypting said associated portion of the information according to a selected encrypting 
20 process based upon said association metadata. 



117. The computer-based method according to claim 1 14, M^erein said association 
metadata represents associations between at least portions of said information and processes for 
informing a user of said information; the method further comprising the steps of 

2S receiving information from said communication channel; 

processing said association metadata to. determine a process for notifying the user when 
information associated with the user is received. 

118. The computer-based method according to claim 1 1 7^ further comprising the steps 

30 of: 

receiving an user input indicating a user preference associated with a notification portion 
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of said infpnpation afi<i ipprp^ntingia processes for infpmiiiig the user of said information; 

determining when said notification portion of said infomiation is receivciid oh sSd 
cp^^WIWri^^sution chaiioel and the usc?r has been notified base^ upon saiid user preference; and 
executing said notification process to notify the user of Teception of said notififi^fibn 
S portion of the infonnationu 



1 1 9. The computer-based method according to claim 1 1 8. wherein said determining 
step includes the step$ of: 

comparing a value in said notification portion of said information with a threshold value; 

10 and 

detOTnining that the user is to be notified of receipt of said notification portion of said 
information when said value exceeds said threshold value. 



120. The computer-based method according to claim 1 07, further comprising the steps 

15 of; 

receiving second information, including second association metadata, from a source 
connected to said communication channel, the first association metadata defming processes for 
transferring information to and from said soirce and a communication entity connected to said 
conununication channel; and 

20 processing said second association metadata to receive third infonnation from said 

communication entity. 

121 . A object-oriented communication stmcttire for implementation on a computer in 
an object-oriented framework, comprising: 

25 a communications object to be transmitted or received on a communication channel 

including: 

at least one data element object; 

at least one page element objects, each page element object being associated with 
one or more data element objects; and 

30 at least one transmission method for transmitting said communications object. 
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122. Tlie dbjeet^rii^tgd cdnmuiucation ^tiiU^tuiie of claim 121, whemih said 
communicadons object furdiCT includes:' 

at least one recipient object associating a recipient connected to said cdmmimications 
channel with said at least one transmission method; and 
5 at least one select method for selecting said at least one recifiient object to transmit said 

communications object to said recipient 

123. The object-oriented commutucation structure of claim 121, wherein s^d at least 
one transmission method includes a method for encoding said coimriunicadbiis object prior to 
transmitting said communication object on said communications channel. 

1 24. The object-oriented conununicadon structure of claim 121, wherein said 
commimications object further includes at least one recipient method for receiving said 
communicationsobject 

123. The object-oriented communication structure of claim 124, wherein said 
commimications object further includes: 

at least one notification element object; and 
at least one preference element object; and 

vyhercih said at least one recipient method includes a notification method for notifying a 
user of notification element objects associated with preference element objects. 

126. The object-oriented conununication structure of claim 124, wherein said at least 
one recipient method includes a display method for displaying said at least one page element 
25 objects. 
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QUESTION/PROiBLEM: 



lit. you ue having a prObiob, pietise try'ip describe vhat you were 
doing prior lo expet'iencing ibe problem. Jliso please include vhac 
you hove already tried to tlx the probleib. 
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